6 SQL Statements
This chapter provides information about the SQL statements available in TimesTen.
SQL statements are generally considered to be either data manipulation language (DML) statements or data definition language (DDL) statements.
DML statements modify database objects. INSERT, UPDATE and DELETE are examples of DML statements. The SELECT statement retrieves data from one or more tables or views.
DDL statements modify the database schema. CREATE TABLE and DROP TABLE are examples of DDL statements.
In addition to an alphabetical listing of all statements, this chapter also contains:
Summary of SQL statements supported in TimesTen
Table 6-1 shows a summary of the SQL statements in TimesTen. The second column indicates if the statement is supported in TimesTen Scaleout. Every statement except ALTER SEQUENCE is supported in TimesTen Classic.
Table 6-1 SQL statements supported in TimesTen
| SQL statement | Supported in TimesTen Scaleout? |
|---|---|
|
N |
|
|
Y |
|
|
N |
|
|
N |
|
|
Y |
|
|
N |
|
|
N |
|
|
Y Not supported in TimesTen Classic. |
|
|
Y |
|
|
Y Unsupported clauses: Aging and column-based compression Unsupported data types: LOB columns are not supported in tables. LOB variables are supported in PL/SQL programs. |
|
|
Y |
|
|
Y |
|
|
Y |
|
|
N |
|
|
Y static read-only with incremental autorefresh |
|
|
Y |
|
|
Y |
|
|
Y with restrictions |
|
|
Y |
|
|
Y |
|
|
Y |
|
|
Y |
|
|
N |
|
|
Y with TimesTen Scaleout specific |
|
|
Y |
|
|
Y including Unsupported clauses: Aging and column-based compression Unsupported data types: LOBs and Distribution clause is not supported for global temporary tables. |
|
|
Y |
|
|
Y |
|
|
Y |
|
|
N |
|
|
Y static read-only cache groups with incremental autorefresh |
|
|
Y |
|
|
Y |
|
|
Y |
|
|
Y |
|
|
Y |
|
|
Y |
|
|
N |
|
|
Y |
|
|
Y |
|
|
Y |
|
|
Y |
|
|
Y |
|
|
N |
|
|
Y |
|
|
Y |
|
|
Y |
|
|
Y static read-only cache groups with incremental autorefresh |
|
|
N |
|
|
Y static read-only cache groups with incremental autorefresh |
|
|
Y |
|
|
Y |
|
|
Y |
|
|
Y, but |
|
|
Y static read-only cache groups with incremental autorefresh |
|
|
Y |
Comments within SQL statements
A comment can appear between keywords, parameters, or punctuation marks in a statement. You can include a comment in a statement in two ways:
-
Begin the comment with a slash and an asterisk (
/*). Proceed with the text of the comment. The text can span multiple lines. End the comment with an asterisk and a slash. (*/). You do not need to separate the opening and terminating characters from the text by a space or line break. -
Begin the comment with two hyphens (
--). Proceed with the text of the comment. The text cannot extend to a new line. End the comment with a line break.
Optimizer hints
Optimizer hints are instructions that are passed to the TimesTen query optimizer. The optimizer considers these hints when choosing the best execution plan for your query. Most of the hints are supported both in TimesTen Scaleout and in TimesTen Classic. There are also hints that are supported only in TimesTen Scaleout. See "Optimizer hints supported in TimesTen Scaleout only" for information.
TimesTen supports three levels of optimizer hints:
-
Statement level optimizer hints: When specified, the optimizer considers the hint for the particular statement. See "Statement level optimizer hints" for details.
-
Transaction level optimizer hints: When specified (by calling the appropriate built-in procedure), the optimizer considers the hint for the entire transaction. See "Use optimizer hints to modify the execution plan" in the Oracle TimesTen In-Memory Database Operations Guide.
-
Connection level optimizer hints: When specified, the optimizer considers the hint for the entire connection. See "Use optimizer hints to modify the execution plan" in the Oracle TimesTen In-Memory Database Operations Guide and "OptimizerHint" in the Oracle TimesTen In-Memory Database Reference for details.
The order of precedence for optimizer hints is statement level hints, transaction level hints and then connection level hints. Table 6-2 provides a summary of the statement, transaction, and connection level optimizer hints.
Table 6-2 Summary of statement, transaction, and connection level optimizer hints
| Statement level optimizer hint | Transaction level optimizer hint | Connection level optimizer hint |
|---|---|---|
|
You specify the hint within the comment syntax and after a |
You specify the hint by calling the |
You specify the hint in the |
|
The hint is scoped to the SQL statement. |
The hint is scoped to the transaction. |
The hint is scoped to the connection. |
|
The |
The |
The |
|
The optimizer considers the hint for the statement only. |
The optimizer considers the hint for all statements in the transaction. |
The optimizer considers the hint for all statements in the connection. |
|
The hint is supported in the |
The hint is not supported in the |
The hint is not supported in the |
|
If you specify the hint in a transaction in which transaction level optimizer hints or connection level optimizer hints are specified, the statement level optimizer hint overrides the transaction level hint or the connection level hint for the SQL statement. After TimesTen executes the SQL statement:
|
The hint is in effect for the duration of the transaction. If you specify a statement level optimizer hint in a SQL statement, the statement level optimizer hint is in effect for the statement and the optimizer does not use the transaction level hint for the statement. After TimesTen executes the statement, the original transaction level optimizer hint remains in effect for the duration of the transaction. A hint specified at this level overrides the same hint specified at the connection level. |
The hints are in effect for the duration of the connection. The order of precedence is statement level, transaction level, and then connection level. |
|
You use the statement level optimizer hints if you want to influence the optimizer for a specific statement. You must specify the hint for each statement in which you want to influence the optimizer. This could result in multiple alterations to your statements. |
You use the transaction level optimizer hints to influence the optimizer for all statements in a transaction. You do not have to specify a hint for each statement. The hint applies to all statements in the transaction. The hint can be overridden by specifying the hint at the statement level. |
You use the connection level optimizer hint to influence the optimizer for all statements in the connection. The hint can be overridden by specifying the hint at the transaction or at the statement level. |
Statement level optimizer hints
Statement level optimizer hints are comments in a SQL statement that pass instructions to the TimesTen query optimizer. The optimizer considers these hints when choosing the best execution plan for your query. It analyzes the SQL statements and generates a query plan which is then used by the SQL execution engine to execute the query and return the data.
See "Use optimizer hints to modify the execution plan" in Oracle TimesTen In-Memory Database Operations Guide for information about statement level optimizer hints.
SQL Syntax
A SQL statement can have one comment that includes one or more statement level optimizer hints.TT_DynamicLoadMultiplePKsTT_DynamicLoadRootTblTT_DynamicPassThrough
Some hints are not supported in certain SQL statements:
-
TT_CommitDMLOnSuccessis supported in theDELETE,INSERT, andUPDATEstatements. It is also valid in theINSERT...SELECTstatement and must follow theSELECTkeyword. This hint is supported in TimesTen Scaleout only. -
The
TT_GridQueryExecandTT_PartialResulthints are supported in theSELECT,INSERT...SELECT, andCREATE TABLE... AS SELECTSQL statements only and these hints must follow theSELECTkeyword. These hints are supported in TimesTen Scaleout only. -
The remaining hints are supported in the
DELETE,INSERT,MERGE,SELECT,UPDATE,INSERT...SELECT, andCREATETABLE...AS SELECTSQL statements and these hints must follow theDELETE,INSERT,MERGE,SELECT, orUPDATEkeyword.
Table 6-3 shows the proper placement of hints in a SQL statement.
You embed statement level optimizer hints in comment syntax. TimesTen supports hints in comments that span one line and in comments that span more than one line. If your comment that contains the hint spans one or more lines, use the comment syntax, /*+...*/. If your comment that contains the hint spans one line, use the comment syntax, --+.
Syntax:
SQL VERB {/*+ [CommentText] hint [{hint|CommentText} [...]] */ | --+ [CommentText] hint [{hint|CommentText} [...]] } hint::= ScaleoutHint | CacheHint | JoinOrderHint | IndexHint| FlagHint ScaleoutHint::= TT_CommitDMLOnSuccess({0|1})|TT_GridQueryExec({LOCAL|GLOBAL})| TT_PartialResult(0|1) CacheHint::= TT_DynamicLoadMultiplePKs ({0|1})|TT_DynamicLoadRootTbl ({0|1})| TT_DynamicPassthrough(N) JoinOrderHint::= TT_JoinOrder (CorrelationName CorrelationName [...]) IndexHint::= TT_Index (CorrelationName,IndexName,{0|1} [;...]) FlagHint::= FlagName (0|1) FlagName::= TT_BranchAndBound|TT_CountAsInt|TT_DynamicLoadEnable| TT_DynamicLoadErrorMode| TT_FirstRow|TT_ForceCompile| TT_GenPlan|TT_HashGb|TT_HashScan|TT_IndexedOr|TT_MergeJoin| TT_NestedLoop|TT_NoRemRowIdOpt|TT_Range|TT_Rowid|TT_RowLock| TT_ShowJoinOrder|TT_TblLock|TT_TblScan|TT_TmpHash|TT_TmpRange| TT_TmpTable|TT_UseBoyerMooreStringSearch|
Parameters
| Parameter | Description |
|---|---|
|
|
The |
|
|
One or more hints that are embedded in comment syntax. The comment syntax can span one or more lines. The plus sign ( Make sure there is no space between the star ( |
|
|
One or more hints that are embedded in comment syntax. The comment syntax can only span one line. The plus sign ( Make sure there is no space between the dash ( |
|
|
A statement level optimizer hint. A SQL statement supports one or more statement level optimizer hints as one comment string. For one SQL statement, you can specify one comment that contains one or more hints and that comment must follow a If you specify more than one hint within the comment, make sure there is a space between the hints. Statement level optimizer hints are scoped to a SQL statement and have per query semantics. For hints other than
|
|
|
Text within a comment string. You can use both statement level optimizer hints and commenting text within one comment. Make sure to include a space between the hint and the commenting text. |
|
|
SELECT /*+TT_GridQueryExec(LOCAL)*/
COUNT(*), elementId# FROM t
GROUP BY elementId#;SELECT /*+TT_GridQueryExec(GLOBAL)*/
COUNT(*), elementId# FROM t
GROUP BY elementId#;SELECT /*+TT_PartialResult(0)*/ COUNT
(*), elementId# FROM t GROUP BY
elementId#;SELECT /*+TT_PartialResult(1)*/ COUNT
(*), elementId# FROM t GROUP BY
elementId#; |
CacheHint |
CacheHint refers to the supported optimizer hints for TimesTen Cache. These hints are TT_DynamicLoadMultiplePKs, TT_DynamicLoadRootTbl, and TT_DynamicPassthrough. These hints are described later in this table (in alphabetical order).
|
|
|
Specify
For example, if you are joining the Command> SELECT /*+ TT_JoinOrder (EMPS DEPTS)*/... If your You can execute the built-in procedure, For more information on |
|
|
Specify a value of 0 to ask the optimizer not to consider the index. Specify a value of 1 to ask the optimizer to consider the index. For example, To direct the optimizer to use the index Command> SELECT /*+ TT_INDEX (E,EMP_NAME_IX,1) */ ... Use a semicolon (;) to include more than one If your You can execute the built-in procedure, For more information on |
|
|
Statement level optimizer hint flags are in effect for the statement only whereas transaction level optimizer hint flags are in effect for the duration of your transaction. |
|
|
Flag that maps to the flag |
|
|
This hint controls the return data type for the This hint is provided for backward compatibility. If you specify the hint with a value of This example specifies a value of Command> describe SELECT /*+TT_CountAsInt(1)*/ COUNT (*) FROM dual;
Prepared Statement:
Columns:
EXP TT_INTEGER NOT NULL
This example specifies a value of Command> describe SELECT /*+TT_CountAsInt(0)*/ COUNT (*) FROM dual;
Prepared Statement:
Columns:
EXP TT_BIGINT NOT NULL
This example does not set the optimizer hint. The default return data type is describe SELECT COUNT (*) FROM dual;
Prepared Statement:
Columns:
EXP TT_BIGINT NOT NULL
|
|
|
Flag that maps to the flag |
|
|
Flag that maps to the flag |
TT_DynamicLoadMultiplePKs{ 0|1} |
TimesTen Cache optimizer hint, supported in TimesTen Classic. This hint enables (if set to 1) or disables (if set to 0), the ability to dynamically load multiple cache instances on a single table cache group. The dynamic load operation must be triggered by a qualified SELECT statement that contains a WHERE clause, in which the WHERE clause references multiple primary key values of the root table of the cache group. The default is 1. When both the TT_DynamicLoadMultiplePKs and the TT_DynamicLoadRootTbl hints are specified, the TT_DynamicLoadMultiplePKs take precedence. See "Dynamically loading multiple cache instances with multiple primary keys" in the Oracle TimesTen In-Memory Database Cache
Guide for details.
|
TT_DynamicLoadRootTbl |
TimesTen Cache optimizer hint, supported in TimesTen Classic. This hint enables (if set to 1) or disables (if set to 0), the ability to dynamically load multiple cache instances on a single table cache group. The dynamic load operation must be triggered by a qualified SELECT statement that contains a WHERE clause, in which the WHERE clause does not reference multiple primary key values of the root table of the cache group. The default is 0. When both the TT_DynamicLoadMultiplePKs and the TT_DynamicLoadRootTbl hints are specified, the TT_DynamicLoadMultiplePKs take precedence. See "Dynamically loading multiple cache instances without multiple primary keys" in the Oracle TimesTen In-Memory Database Cache
Guide for details.
|
TT_DynamicPassThrough(N) |
TimesTen Cache optimizer hint, supported in TimesTen Classic. If specified, this hint limits the number of rows that can be dynamically loaded into a TimesTen cache instance. Specifically, if a dynamic load operation triggered by a qualified SELECT statement results in a number of rows that is greater than the specified N row limit, the cache instance is not loaded and instead the query is passed to the Oracle database. The dynamic load must be triggered by a qualified SELECT statement and the cache group must not have a WHERE clause. The hint is ignored for non-SELECT statements. Set this hint to the maximum number of rows you want dynamically loaded. If you set the hint to a value less than or equal to 0 or if you do not specify the hint, the dynamic load has no row limit. In this case, there is not a limit in the number of rows can be loaded into the cache instance. See "Automatic passthrough of dynamic load to the Oracle database" in the Oracle TimesTen In-Memory Database Cache
Guide for details.
|
|
|
Flag that maps to the flag |
|
|
Flag that maps to the flag |
|
|
Flag that maps to the flag |
|
|
Flag that maps to the flag |
|
|
Flag that maps to the flag |
|
|
Flag that maps to the flag |
|
|
Flag that maps to the flag |
|
|
Flag that maps to the flag |
|
|
Flag that maps to the flag |
|
|
Flag that maps to the flag |
|
|
Flag that maps to the flag |
|
|
Flag that maps to the flag |
|
|
Flag that maps to the flag |
|
|
Flag that maps to the flag |
|
|
Flag that maps to the flag |
|
|
Flag that maps to the flag |
|
|
Flag that maps to the flag |
|
|
Flag that maps to the flag |
|
|
Flag that maps to the flag |
Note:
For descriptions of flags discussed in the preceding table, see "ttOptSetFlag" in the Oracle TimesTen In-Memory Database Reference
Description
-
Embed statement level optimizer hints in comment syntax. Begin the comment with either
/*or--. Follow the beginning comment syntax with a plus sign (+). The plus sign (+) signals TimesTen to interpret the comment as a list of hints. The plus sign (+) must follow immediately after the comment delimiter. (For example, after/*or after--). No space is permitted between the comment delimiter and the plus sign (+).In the following example, there is a space between the star (*) and the plus sign (+), so the hint is ignored:
Command> SELECT /* + TT_TblScan (1) This hint is ignored because there is a space between the star (*) and the plus (+) sign. */ ...
-
A
hintis one of the statement level optimizer hints supported by TimesTen. There can be a space between the plus sign (+) and the hint. If the comment contains multiple hints, separate the hints by at least one space. For example, to specify two hints on one line:Command> SELECT --+ TT_MergeJoin (0) TT_NestedLoop (1) ...
-
You can intersperse commenting text with hints in a comment. For example,
Command> SELECT /*+ TT_HashScan (1) This demonstrates a hint followed by a comment string. */ ...
-
TimesTen ignores hints and does not return an error if:
-
Your hint does not follow the
DELETE,INSERT,MERGE,SELECTorUPDATEkeyword (or forTT_GridQueryExecorTT_PartialResult, theSELECTkeyword).TT_CommitDMLOnSuccessmust follow theDELETE,INSERT,UPDATEkeyword and forINSERT...SELECT, it must follow theSELECTkeyword. -
Your hint contains misspellings or syntax errors. If you have hints that are within the same comment and some hints are correct syntactically and some hints are incorrect syntactically, TimesTen ignores the incorrect hints and accepts the correct hints.
-
You use either the
TT_JoinOrderorTT_Indexhint and you do not supply a closing parenthesis, the remainder of the hint string is ignored.
-
-
For hints that conflict with each other, TimesTen uses the rightmost hint in the comment. For example, if the comment string is
/*+TT_TblScan (0)...TT_TblScan (1) */, the rightmost hint,TT_TblScan(1), is used. -
Statement level optimizer hints override conflicting transaction level optimizer hints. If you specify a transaction level optimizer hint that conflicts with a statement level optimizer hint, the statement level optimizer hint overrides the conflicting transaction level optimizer hint. For example, if you call
ttOptSetFlag, and enable theRangeflag and then you issue a SQL query and disable the statement level optimizer flag,TT_Range, TimesTen disables the range flag for the query. After the query is executed, the original range flag setting that was in place in the transaction before the query was executed remains in effect for the duration of the transaction. For more information, see "Using statement level optimizer hints for a SELECT query". TheTT_GridQueryExec,TT_PartialResult,TT_CommitDMLOnSuccess, andTT_CountAsInthints are not supported at the transaction level. -
Do not use statement level optimizer hints in a subquery.
-
The TimesTen query optimizer does not recognize statement level optimizer hints for passthrough statements. TimesTen passes the SQL text for passthrough statements to the Oracle database and the SQL text is processed according to the SQL rules of the Oracle database. Passthrough statements are not supported in TimesTen Scaleout.
SQL statements that support statement level optimizer hints
You can specify statement level optimizer hints in SQL statements. Not all hints are supported in all statements. You must specify the hint within comment syntax and the comment syntax must immediately follow the SQL VERB. (For example, SELECT /*+ hint */...) Table 6-3 shows the correct placement of the statement level hint. It also indicates if a hint is not supported in the statement.
Table 6-3 Placement of statement level hints in SQL statements
| SQL statement | Placement of hint |
|---|---|
|
|
Do not use transaction level hints with the
|
|
|
The |
|
|
The |
|
|
|
|
|
The |
|
|
Do not specify a hint in a subquery. The |
|
|
The |
|
|
The |
Understanding hints
Use optimizer hints to influence the TimesTen query optimizer in determining the choice of the execution plan for your query.
TT_GridQueryExec, TT_PartialResult and TT_CommitDMLOnSuccess are supported at the connection and statement levels only. This section is not valid for these hints.
To view transaction level optimizer hints, execute the built-in procedure, ttOptSetFlag. For more information on the built-in procedure, ttOptGetFlag, see "ttOptGetFlag" in Oracle TimesTen In-Memory Database Reference.
Examples
For TT_CommitDMLOnSuccess examples, see "TT_CommitDMLOnSuccess optimizer hint" for information.
For TT_GridQueryExec and TT_PartialResult examples:
-
See "TT_GridQueryExec" in the Oracle TimesTen In-Memory Database Scaleout User's Guide.
-
See "TT_PartialResult" in the Oracle TimesTen In-Memory Database Scaleout User's Guide.
The following examples illustrate usages of statement level and transaction level optimizer hints. The TimesTen optimizer is a cost based query optimizer and generates what it thinks is the most optimal execution plan for your statement. This plan differs from release to release. The plan is based on the indexes that exist on the referenced tables as well as the column and table statistics that are available. When you recompute statistics or change indexes, the TimesTen optimizer may change the execution plan based on the recomputed statistics and index changes. Because the execution plan may vary, these examples are included for demonstration purposes only. Examples include:
Using statement level optimizer hints for a SELECT query
View the execution plan for a query. Then use statement level optimizer hints to influence the optimizer to choose a different execution plan. Consider the query:
Command> SELECT r.region_name, c.country_name
FROM regions r, countries c
WHERE r.region_id = c.region_id
ORDER BY c.region_id;
Use the ttIsql EXPLAIN command to view the plan generated by the optimizer. Note:
-
The optimizer performs two range scans using table level locking for both scans.
-
The optimizer uses the
MergeJoinoperation to join the two tables.
Command> EXPLAIN SELECT r.region_name, c.country_name
FROM regions r, countries c
WHERE r.region_id = c.region_id
ORDER BY c.region_id;
Query Optimizer Plan:
STEP: 1
LEVEL: 2
OPERATION: TblLkRangeScan
TBLNAME: COUNTRIES
IXNAME: COUNTR_REG_FK
INDEXED CONDITION: <NULL>
NOT INDEXED: <NULL>
STEP: 2
LEVEL: 2
OPERATION: TblLkRangeScan
TBLNAME: REGIONS
IXNAME: REGIONS
INDEXED CONDITION: R.REGION_ID >= C.REGION_ID
NOT INDEXED: <NULL>
STEP: 3
LEVEL: 1
OPERATION: MergeJoin
TBLNAME: <NULL>
IXNAME: <NULL>
INDEXED CONDITION: C.REGION_ID = R.REGION_ID
NOT INDEXED: <NULL>
Now use statement level optimizer hints to direct the optimizer to perform the scans using row level locking and to use a NestedLoop operation to join the tables. Set autocommit to on to illustrate that the autocommit setting has no effect because statement level optimizer hints are scoped to the SQL statement.
Command> autocommit on;
Command> EXPLAIN SELECT /*+ TT_RowLock (1), TT_TblLock (0), TT_MergeJoin (0),
TT_NestedLoop (1) */
r.region_name, c.country_name
FROM regions r, countries c
WHERE r.region_id = c.region_id
ORDER BY c.region_id;
Query Optimizer Plan:
STEP: 1
LEVEL: 3
OPERATION: RowLkRangeScan
TBLNAME: REGIONS
IXNAME: REGIONS
INDEXED CONDITION: <NULL>
NOT INDEXED: <NULL>
STEP: 2
LEVEL: 3
OPERATION: RowLkRangeScan
TBLNAME: COUNTRIES
IXNAME: COUNTR_REG_FK
INDEXED CONDITION: C.REGION_ID = R.REGION_ID
NOT INDEXED: <NULL>
STEP: 3
LEVEL: 2
OPERATION: NestedLoop
TBLNAME: <NULL>
IXNAME: <NULL>
INDEXED CONDITION: <NULL>
NOT INDEXED: <NULL>
STEP: 4
LEVEL: 1
OPERATION: OrderBy
TBLNAME: <NULL>
IXNAME: <NULL>
INDEXED CONDITION: <NULL>
NOT INDEXED: <NULL>
Prepare the query again without statement level optimizer hints. The optimizer reverts back to the original execution plan because statement level optimizer hints are scoped to the SQL statement.
Command> EXPLAIN SELECT r.region_name, c.country_name
FROM regions r, countries c
WHERE r.region_id = c.region_id
ORDER BY c.region_id;
Query Optimizer Plan:
STEP: 1
LEVEL: 2
OPERATION: TblLkRangeScan
TBLNAME: COUNTRIES
IXNAME: COUNTR_REG_FK
INDEXED CONDITION: <NULL>
NOT INDEXED: <NULL>
STEP: 2
LEVEL: 2
OPERATION: TblLkRangeScan
TBLNAME: REGIONS
IXNAME: REGIONS
INDEXED CONDITION: R.REGION_ID >= C.REGION_ID
NOT INDEXED: <NULL>
STEP: 3
LEVEL: 1
OPERATION: MergeJoin
TBLNAME: <NULL>
IXNAME: <NULL>
INDEXED CONDITION: C.REGION_ID = R.REGION_ID
NOT INDEXED: <NULL>Using on and off hinting
This example illustrates the importance of directing the optimizer to specifically enable or disable hints that perform a similar function. For example, the hash and range hints direct the optimizer to use either a hash or range access path for the table. In order to ensure the optimizer chooses the specific access path, enable one hint and disable all other related hints.
Create a table and create a hash index on the first column of the table and a range index on the second column.
Command> CREATE TABLE test (col1 NUMBER, col2 NUMBER); Command> CREATE HASH INDEX h_index ON test (col1); Command> CREATE INDEX hr_index ON test (col2);
Set autocommit to off and execute the built-in procedure, ttOptGetFlag, to review the current transaction level optimizer hint settings for the transaction. A setting of 1 means the flag is enabled.
Command> autocommit off;
Command> CALL ttOptGetFlag ('Hash');
< Hash, 1 >
1 row found.
Command> CALL ttOptGetFlag ('Scan');
< Scan, 1 >
1 row found.
Use the ttIsql EXPLAIN command to review the plan for a SELECT query using a WHERE clause and dynamic parameters. The optimizer uses a hash scan.
Command> EXPLAIN SELECT * FROM test WHERE col1 = ? and col2 = ?; Query Optimizer Plan: STEP: 1 LEVEL: 1 OPERATION: RowLkHashScan TBLNAME: TEST IXNAME: H_INDEX INDEXED CONDITION: TEST.COL1 = _QMARK_1 NOT INDEXED: TEST.COL2 = _QMARK_2
Use the statement level optimizer hint TT_Range to direct the optimizer to use a range scan. Note that the optimizer ignores the TT_Range hint and uses a hash scan because you did not direct the optimizer to disable the hash scan. Alter the statement and direct the optimizer to use a range scan and not use a hash scan. To accomplish this, enable the statement level optimizer hint TT_Range and disable the statement level optimizer hint TT_HashScan. The optimizer no longer ignores the TT_Range hint.
Command> EXPLAIN SELECT --+ TT_Range (1) Single line comment to set TT_Range
* FROM TEST WHERE col1 = ? and col2 = ?;
Query Optimizer Plan:
STEP: 1
LEVEL: 1
OPERATION: RowLkHashScan
TBLNAME: TEST
IXNAME: H_INDEX
INDEXED CONDITION: TEST.COL1 = _QMARK_1
NOT INDEXED: TEST.COL2 = _QMARK_2
Command> EXPLAIN SELECT /*+ TT_Range (1) TT_HashScan (0)
Multiple line comment to enable TT_Range and disable TT_HashScan */
* FROM TEST WHERE col1 = ? and col2 = ?;
Query Optimizer Plan:
STEP: 1
LEVEL: 1
OPERATION: RowLkRangeScan
TBLNAME: TEST
IXNAME: HR_INDEX
INDEXED CONDITION: TEST.COL2 = _QMARK_2
NOT INDEXED: TEST.COL1 = _QMARK_1
Prepare the query again without using statement level optimizer hints and without issuing a commit or rollback. The optimizer uses the transaction level optimizer hints settings that were in effect before executing the query. The optimizer uses transaction level optimizer hints because statement level optimizer hints are scoped to the SQL statement.
Command> EXPLAIN SELECT * FROM TEST WHERE col1 = ? and col2 = ?; Query Optimizer Plan: STEP: 1 LEVEL: 1 OPERATION: RowLkHashScan TBLNAME: TEST IXNAME: H_INDEX INDEXED CONDITION: TEST.COL1 = _QMARK_1 NOT INDEXED: TEST.COL2 = _QMARK_2
Using TT_JoinOrder to specify a join order
Use the statement level optimizer hint TT_JoinOrder to direct the optimizer to use a specific join order. First use a transaction level optimizer hint to direct the optimizer to use a specific join order for the transaction. Then use a statement level optimizer hint to direct the optimizer to change the join order for the statement only.
Command> CALL ttOptSetOrder ('e d j');
Command> EXPLAIN SELECT *
FROM employees e, departments d, job_history j
WHERE e.department_id = d.department_id
AND e.hire_date = j.start_date;
Query Optimizer Plan:
STEP: 1
LEVEL: 3
OPERATION: TblLkRangeScan
TBLNAME: EMPLOYEES
IXNAME: EMP_DEPT_FK
INDEXED CONDITION: <NULL>
NOT INDEXED: <NULL>
STEP: 2
LEVEL: 3
OPERATION: TblLkRangeScan
TBLNAME: DEPARTMENTS
IXNAME: DEPARTMENTS
INDEXED CONDITION: D.DEPARTMENT_ID >= E.DEPARTMENT_ID
NOT INDEXED: <NULL>
STEP: 3
LEVEL: 2
OPERATION: MergeJoin
TBLNAME: <NULL>
IXNAME: <NULL>
INDEXED CONDITION: E.DEPARTMENT_ID = D.DEPARTMENT_ID
NOT INDEXED: <NULL>
STEP: 4
LEVEL: 2
OPERATION: TblLkRangeScan
TBLNAME: JOB_HISTORY
IXNAME: JOB_HISTORY
INDEXED CONDITION: <NULL>
NOT INDEXED: E.HIRE_DATE = J.START_DATE
STEP: 5
LEVEL: 1
OPERATION: NestedLoop
TBLNAME: <NULL>
IXNAME: <NULL>
INDEXED CONDITION: <NULL>
NOT INDEXED: <NULL>
Use the statement level optimizer hint, TT_JoinOrder, to direct the optimizer to override the transaction level join order optimizer hint for the SQL statement only.
Command> EXPLAIN SELECT --+ TT_JoinOrder (e j d)
*
FROM employees e, departments d, job_history j
WHERE e.department_id = d.department_id
AND e.hire_date = j.start_date;
Query Optimizer Plan:
STEP: 1
LEVEL: 3
OPERATION: TblLkRangeScan
TBLNAME: EMPLOYEES
IXNAME: EMP_DEPT_FK
INDEXED CONDITION: <NULL>
NOT INDEXED: <NULL>
STEP: 2
LEVEL: 3
OPERATION: TblLkRangeScan
TBLNAME: JOB_HISTORY
IXNAME: JOB_HISTORY
INDEXED CONDITION: <NULL>
NOT INDEXED: E.HIRE_DATE = J.START_DATE
STEP: 3
LEVEL: 2
OPERATION: NestedLoop
TBLNAME: <NULL>
IXNAME: <NULL>
INDEXED CONDITION: <NULL>
NOT INDEXED: <NULL>
STEP: 4
LEVEL: 2
OPERATION: TblLkRangeScan
TBLNAME: DEPARTMENTS
IXNAME: DEPARTMENTS
INDEXED CONDITION: D.DEPARTMENT_ID >= E.DEPARTMENT_ID
NOT INDEXED: <NULL>
STEP: 5
LEVEL: 1
OPERATION: MergeJoin
TBLNAME: <NULL>
IXNAME: <NULL>
INDEXED CONDITION: E.DEPARTMENT_ID = D.DEPARTMENT_ID
NOT INDEXED: <NULL>
Prepare the query again to verify that the join order that was in effect for the transaction remains in effect.
Command> EXPLAIN SELECT *
FROM employees e, departments d, job_history j
WHERE e.department_id = d.department_id
AND e.hire_date = j.start_date;
Query Optimizer Plan:
STEP: 1
LEVEL: 3
OPERATION: TblLkRangeScan
TBLNAME: EMPLOYEES
IXNAME: EMP_DEPT_FK
INDEXED CONDITION: <NULL>
NOT INDEXED: <NULL>
STEP: 2
LEVEL: 3
OPERATION: TblLkRangeScan
TBLNAME: DEPARTMENTS
IXNAME: DEPARTMENTS
INDEXED CONDITION: D.DEPARTMENT_ID >= E.DEPARTMENT_ID
NOT INDEXED: <NULL>
STEP: 3
LEVEL: 2
OPERATION: MergeJoin
TBLNAME: <NULL>
IXNAME: <NULL>
INDEXED CONDITION: E.DEPARTMENT_ID = D.DEPARTMENT_ID
NOT INDEXED: <NULL>
STEP: 4
LEVEL: 2
OPERATION: TblLkRangeScan
TBLNAME: JOB_HISTORY
IXNAME: JOB_HISTORY
INDEXED CONDITION: <NULL>
NOT INDEXED: E.HIRE_DATE = J.START_DATE
STEP: 5
LEVEL: 1
OPERATION: NestedLoop
TBLNAME: <NULL>
IXNAME: <NULL>
INDEXED CONDITION: <NULL>
NOT INDEXED: <NULL>Using the statement level optimizer hint TT_INDEX
Perform a query on the employees table that uses the index, emp_name_ix. Then use the statement level optimizer hint TT_INDEX to direct the optimizer not to use this index. First run the ttIsql command, indexes, to view the indexes for the employees table.
Command> indexes employees;
Indexes on table TESTUSER.EMPLOYEES:
EMPLOYEES: unique range index on columns:
EMPLOYEE_ID
(referenced by foreign key index JHIST_EMP_FK on table TESTUSER.JOB_HISTORY)
TTUNIQUE_0: unique range index on columns:
EMAIL
EMP_DEPT_FK: non-unique range index on columns:
DEPARTMENT_ID
(foreign key index references table TESTUSER.DEPARTMENTS(DEPARTMENT_ID))
EMP_JOB_FK: non-unique range index on columns:
JOB_ID
(foreign key index references table TESTUSER.JOBS(JOB_ID))
EMP_NAME_IX: non-unique range index on columns:
LAST_NAME
FIRST_NAME
5 indexes found.
5 indexes found on 1 table.
Use the ttIsql command, EXPLAIN, to view the execution plan for a SELECT query on the employees table that uses a WHERE clause on the last_name column.
Command> EXPLAIN SELECT e.first_name
FROM employees e
WHERE e.last_name BETWEEN 'A' AND 'B';
Query Optimizer Plan:
STEP: 1
LEVEL: 1
OPERATION: RowLkRangeScan
TBLNAME: EMPLOYEES
IXNAME: EMP_NAME_IX
INDEXED CONDITION: E.LAST_NAME >= 'A' AND E.LAST_NAME <= 'B'
NOT INDEXED: <NULL>
Use the statement level optimizer hint, TT_INDEX, to direct the optimizer not to use the index, emp_name_ix.
Command> EXPLAIN SELECT --+ TT_INDEX (E,EMP_NAME_IX,0)
e.first_name
FROM employees e
WHERE e.last_name BETWEEN 'A' AND 'B';
Query Optimizer Plan:
STEP: 1
LEVEL: 1
OPERATION: TblLkRangeScan
TBLNAME: EMPLOYEES
IXNAME: EMPLOYEES
INDEXED CONDITION: <NULL>
NOT INDEXED: E.LAST_NAME <= 'B' AND E.LAST_NAME >= 'A'Optimizer hints supported in TimesTen Scaleout only
These optimizer hints are only supported in TimesTen Scaleout. They are valid at the statement and at the connection levels.
See "OptimizerHint" in the Oracle TimesTen In-Memory Database Reference for information on hints at the connection level and "Statement level optimizer hints" in this book for information on statement level optimizer hints.
TT_GridQueryExec optimizer hint
The TT_GridQueryExec optimizer hint enables you to specify whether the query should return data from the local element or from all elements, including the elements in a replica set when K-safety is set to 2.
If you do not specify this hint, the query is executed in one logical data space. It is neither local nor global. This means that exactly one full copy of the data is used to compute the query. Use this hint in cases where obtaining some result is more important than obtaining the correct result (for example, where one or more replica sets are unavailable). Valid options for this hint are LOCAL and GLOBAL.
For more information, see:
-
"TT_GridQueryExec" in the Oracle TimesTen In-Memory Database Scaleout User's Guide for information on using this hint.
-
"OptimizerHint" in the Oracle TimesTen In-Memory Database Reference for information on using this hint at the connection level.
-
"Statement level optimizer hints" for information on using this hint at the statement level.
This example illustrates how to use the TT_GridQueryExec(GLOBAL) hint on the dual table to determine the ids of all elements, replica sets, and dataspaces.
Command> SELECT /*+TT_GridQueryExec(GLOBAL)*/ elementId#, replicasetId#,
dataspaceId# FROM dual ORDER BY elementId#,replicasetId#,dataspaceId#;
ELEMENTID#, REPLICASETID#, DATASPACEID#
< 1, 1, 1 >
< 2, 1, 2 >
< 3, 2, 1 >
< 4, 2, 2 >
< 5, 3, 1 >
< 6, 3, 2 >
6 rows found.
See "TT_GridQueryExec" in the Oracle TimesTen In-Memory Database Scaleout User's Guide for more examples.
TT_PartialResult optimizer hint
The TT_PartialResult optimizer hint enables you to specify whether the query should return partial results if some data is not available.
Use TT_PartialResult(1) to direct the query to return partial results if all elements in a replica set are not available.
Use TT_PartialResult(0) to direct the query to return an error if the required data is not available in the case where all elements in a replica set are not available. If at least one element from each replica set is available or the data required by the query is available, the optimizer returns the query result correctly without error.
The default is TT_PartialResult(0).
For more information, see:
-
"TT_PartialResult" in the Oracle TimesTen In-Memory Database Scaleout User's Guide for information on using this hint and for examples.
-
"OptimizerHint" in the Oracle TimesTen In-Memory Database Reference for information on using this hint at the connection level.
-
"Statement level optimizer hints" for information on using this hint at the statement level.
TT_CommitDMLOnSuccess optimizer hint
Use the TT_CommitDMLOnSuccess hit to enable or disable a commit operation as part of DML execution.
-
At the statement level,
TT_CommitDMLOnSuccessis used in a DML statement (DELETE,INSERT,INSERT... SELECT, andUPDATE) to enable or disable the commit behavior of the transaction when the DML operation is executed. For theINSERT...SELECTstatement, specifyTT_CommitDMLOnSuccessafter theSELECTkeyword.TT_CommitDMLOnSuccessis valid in DML operations only. It is not valid for queries or DDL operations and, if specified in a non-DML statement, is ignored and no error is returned. See "Statement level optimizer hints" for information on the syntax and semantics. -
At the connection level,
TT_CommitDMLOnSuccessis also used to enable or disable the commit behavior of the transaction when a DML operation is executed. However, you specifyTT_CommitDMLOnSuccessas a parameter to theOptimizerHintconnection attribute. See "OptimizerHint" in the Oracle TimesTen In-Memory Database Reference for information on usingTT_CommitDMLOnSuccessat the connection level.
At both levels, valid options are 0 and 1. If you do not specify TT_CommitDMLOnSuccess, there are no changes to the normal commit behavior. The order of precedence is statement level followed by connection level.
The TT_CommitDMLOnSuccess commit behavior at the statement level is:
-
TT_CommitDMLOnSuccess(1)commits the current transaction if the DML statement in which the hint is specified is executed successfully. If there are open cursors at commit time, all cursors are closed and the transaction is committed. If the statement with this hint fails, the transaction is not committed. -
TT_CommitDMLOnSuccess(0)disables the commit of the current transaction if the DML statement in which the hint is specified is executed successfully.
Table 6-4 shows the commit behavior when not setting TT_CommitDMLOnSuccess as well as setting TT_CommitDMLOnSuccess to 0 and 1 at the statement and connection levels. The table shows the commit behavior when autocommit is set to 0.
Table 6-5 shows the commit behavior when not setting TT_CommitDMLOnSuccess as well as setting TT_CommitDMLOnSuccess to 0 and 1 at the statement and connection levels. The table shows the commit behavior when autocommit is set to 1.
Table 6-4 TT_CommitDMLOnSuccess commit behavior: Autocommit 0
| Blank | Not set at connection level | Set to 0 at connection level | Set to 1 at connection level |
|---|---|---|---|
|
Not set at statement level |
|
|
|
|
Set to 0 at statement level |
|
|
|
|
Set to 1 at statement level |
|
|
|
Table 6-5 TT_CommitDMLOnSuccess commit behavior: Autocommit 1
| Blank | Not set at connection level | Set to 0 at connection level | Set to 1 at connection level |
|---|---|---|---|
|
Not set at statement level |
|
|
|
|
Set to 0 at statement level |
|
|
|
|
Set to 1 at statement level |
|
|
|
For more information, see:
-
"Using the TT_CommitDMLOnSuccess hint" in the Oracle TimesTen In-Memory Database Scaleout User's Guide for additional information.
-
"OptimizerHint" in the Oracle TimesTen In-Memory Database Reference for information on using
TT_CommitDMLOnSuccessat the connection level. -
"Statement level optimizer hints" for information on the syntax for
TT_CommitDMLOnSuccessat the statement level.
These examples illustrate the use of the TT_CommitDMLOnSuccess optimizer hint:
Setting TT_CommitDMLOnSuccess to 1
This example first creates the mytable table. It then sets autocommit to 0 and inserts a row into the mytable table. A second connection (conn2) connects to the database and issues a SELECT query against the mytable table. The query returns 0 rows. The ttIsql use command returns the application to the first connection (database1) and issues a second INSERT operation, setting TT_CommitDMLOnSuccess to 1 at the statement level. A second ttIsql use command returns the application to the conn2 connection. A SELECT query shows two rows have been inserted into the mytable table. This example illustrates that issuing TT_CommitDMLOnSuccess(1) commits the transaction after the successful execution of the second INSERT operation (which set the hint).
Command> CREATE TABLE mytable (col1 TT_INTEGER, col2 VARCHAR2(4000)); Command> autocommit 0; Command> INSERT INTO mytable VALUES (10, 'ABC'); 1 row inserted.
Establish a second connection (conn2)
Command> connect as conn2; Using the connection string of connection database1 to connect... ... (Default setting AutoCommit=1)
Issue a SELECT query and expect 0 rows due to autocommit set to 0.
conn2: Command> SELECT * FROM mytable; 0 rows found.
Return to the first connection (database1) and issue an INSERT operation with TT_CommitDMLOnSuccess set to 1.
conn2: Command> use database1;
database1: Command> INSERT /*+TT_CommitDMLOnSuccess(1)*/
INTO mytable VALUES (10, 'ABC');
1 row inserted.
Return to the second connection (conn2) and issue a SELECT query. Expect 2 rows (due to the two INSERT statements. (The transaction is committed due to the TT_CommitDMLOnSuccess statement level hint set to 1 and the successful execution of the two INSERT operations.)
database1: Command> use conn2 conn2: Command> SELECT * FROM mytable; < 10, ABC > < 10, ABC > 2 rows found.
Using TT_CommitDMLOnSuccess at connection level
This example first creates the mytable table. It then uses PL/SQL to insert 1000 rows into the table. There is a second connection to the database (conn2) and this connection connects with TT_CommitDMLOnSuccess set to 1 at the connection level. Various operations are performed to illustrate the behavior of TT_CommitDMLOnSuccess at both the statement and connection levels.
Command> CREATE TABLE mytable (col1 TT_INTEGER NOT NULL PRIMARY KEY,
col2 VARCHAR2 (4000));
Command> BEGIN
FOR i in 1..1000
LOOP
INSERT INTO mytable VALUES (i,i);
END LOOP;
END;
/
PL/SQL procedure successfully completed.
Establish a second connection (conn2) and connect setting TT_CommitDMLOnSuccess at the connection level to 1.
Command> CONNECT adding "OptimizerHint=TT_CommitDMLOnSuccess(1)" as conn2; Connection successful: ...
Set autocommit to 0 and issue a DELETE operation.
conn2: Command> autocommit 0; conn2: Command> DELETE FROM mytable WHERE col1=1000; 1 row deleted.
Return to the original connection (database1) and issue a SELECT query to see if the DELETE operation was committed. The operation was committed due to the TT_CommitDMLOnSuccess setting of 1 at the connection level.
conn2: Command> use database1; database1: Command> SELECT * FROM mytable WHERE col1=1000; 0 rows found.
Return to the second connection (conn2) and issue an INSERT operation. Then return to the original connection (database1). The transaction containing the INSERT operation was committed.
database1: Command> use conn2; conn2: Command> INSERT INTO mytable VALUES (1000,1000); 1 row inserted. conn2: Command> use database1 database1: Command> SELECT * FROM mytable WHERE col1=1000; < 1000, 1000 > 1 row found.
Return to the second connection (conn2) and issue a DELETE operation, followed by an INSERT operation, and then a second INSERT operation where TT_CommitDMLOnSuccess is set to 0 at the statement level (the second INSERT).
database1: Command> use conn2;
conn2: Command> DELETE FROM mytable WHERE col1=1000;
1 row deleted.
conn2: Command> INSERT INTO mytable VALUES (1001,1001);
1 row inserted.
conn2: Command> INSERT /*+TT_CommitDMLOnSuccess(0)*/ INTO mytable
VALUES (1002,1002);
1 row inserted.
Issue a SELECT query and notice the results of the query. The one DELETE operation and the two INSERT operations were successful.
conn2: Command> SELECT * FROM mytable where col1 >= 1000; < 1001, 1001 > < 1002, 1002 > 2 rows found.
Return to the original connection (database1) and issue the same SELECT query. Observe that the one DELETE statement and the first INSERT operation were committed. This is due to the TT_CommitDMLOnSuccess setting of 1 at the connection level. The second INSERT statement was not committed due to the TT_CommitDMLOnSuccess setting of 0 for this second INSERT statement.
conn2: Command> use database1; database1: Command> SELECT * FROM mytable where col1 >= 1000; < 1001, 1001 > 1 row found.
Return to the second connection (conn2) and issue a third INSERT operation. Then issue a SELECT query and observe the results.
database1: Command> use conn2; conn2: Command> INSERT INTO mytable VALUES (1003,1003); 1 row inserted. conn2: Command> SELECT * FROM mytable where col1 >= 1000 ORDER BY col1; < 1001, 1001 > < 1002, 1002 > < 1003, 1003 > 3 rows found.
Return to the original connection (database1) and issue the same SELECT query. Note the results are the same as in the conn2 connection. The transaction is committed due to the TT_CommitDMLOnSuccess setting of 1 at the connection level and the successful execution of the second and third INSERT operations.
conn2: Command> use database1 database1: Command> SELECT * FROM mytable where col1 >= 1000 ORDER BY col1; < 1001, 1001 > < 1002, 1002 > < 1003, 1003 > 3 rows found.
ALTER ACTIVE STANDBY PAIR
This statement is not supported in TimesTen Scaleout.
In TimesTen Classic:
You can change an active standby pair by:
-
Adding or dropping a subscriber database
-
Altering store attributes
Only the
PORTandTIMEOUTattributes can be set for subscribers. -
Including tables, sequences or cache groups in the replication scheme
-
Excluding tables, sequences or cache groups from the replication scheme
See "Making other changes to an active standby pair" in Oracle TimesTen In-Memory Database Replication Guide.
Required privilege
ADMIN
Usage with TimesTen Scaleout
This statement is not supported with TimesTen Scaleout.
SQL syntax
ALTER ACTIVE STANDBY PAIR {
SubscriberOperation |
StoreOperation | InclusionOperation |
NetworkOperation } [...]
Syntax for SubscriberOperation:
{ADD | DROP } SUBSCRIBER FullStoreName
Syntax for StoreOperation:
ALTER STOREFullStoreNameSETStoreAttribute
Syntax for InclusionOperation:
[{ INCLUDE | EXCLUDE }{TABLE [[Owner.]TableName [,...]]|
CACHE GROUP [[Owner.]CacheGroupName [,...]]|
SEQUENCE [[Owner.]SequenceName [,...]]} [,...]]
Syntax for NetworkOperation:
ADD ROUTE MASTER FullStoreName SUBSCRIBER FullStoreName { { MASTERIP MasterHost | SUBSCRIBERIP SubscriberHost } PRIORITY Priority } [...] DROP ROUTE MASTER FullStoreName SUBSCRIBER FullStoreName { MASTERIP MasterHost | SUBSCRIBERIP SubscriberHost } [...]
Parameters
| Parameter | Description |
|---|---|
|
|
Indicates a subscriber database. |
|
|
Indicates that updates should no longer be sent to the specified subscriber database. This operation fails if the replication scheme has only one subscriber. |
|
|
Indicates changes to the attributes of a database. Only the See "CREATE ACTIVE STANDBY PAIR" For information on |
|
|
The database, specified as one of the following:
For example, if the database path is This is the database file name specified in the
|
|
|
Includes in or excludes from replication the tables, sequences or cache groups listed.
You cannot use the |
|
|
Adds Can be specified more than once. For |
|
|
Drops Can be specified more than once. For |
|
|
Clause can be specified more than once. Valid for both |
|
|
Variable expressed as an integer from 1 to 99. Denotes the priority of the IP address. Lower integral values have higher priority. An error is returned if multiple addresses with the same priority are specified. Controls the order in which multiple IP addresses are used to establish peer connections. Required syntax of |
Description
-
You must stop the replication agent before altering an active standby pair. The exceptions are for those objects and statements that are automatically replicated and included based on the values of the
DDL_REPLICATION_LEVELandDDL_REPLICATION_ACTIONattributes. See "ALTER SESSION" for more information. -
You may only alter the active standby pair replication scheme on the active database. See "Making other changes to an active standby pair" in Oracle TimesTen In-Memory Database Replication Guide for more information.
-
You may not use
ALTER ACTIVE STANDBY PAIRwhen using Oracle Clusterware with TimesTen. See "Restricted commands and SQL statements" in Oracle TimesTen In-Memory Database Replication Guide for more information.Instead, perform the tasks described in "Changing the schema" section of the Oracle TimesTen In-Memory Database Replication Guide.
-
Use
ADD SUBSCRIBERFullStoreNameto add a subscriber to the replication scheme. -
Use
DROP SUBSCRIBERFullStoreNameto drop a subscriber from the replication scheme. -
Use the
INCLUDEorEXCLUDEclause to include the listed tables, sequences or cache groups in the replication scheme or to exclude them from the replication scheme. Use oneINCLUDEorEXCLUDEclause for each object type (table, sequence or cache group). TheALTER ACTIVE STANDBYstatement is not necessary for those objects and statements that are automatically replicated and included based on the values of theDDL_REPLICATION_LEVELandDDL_REPLICATION_ACTIONattributes. See "ALTER SESSION" for more information. However, ifDDL_REPLICATION_LEVELis 2 or greater andDDL_REPLICATION_ACTION="EXCLUDE", use theINCLUDEclause to include replicated objects into the replication scheme. -
Do not use the
EXCLUDEclause for AWT cache groups. -
When
DDL_REPLICATION_LEVELis 2 or greater, theINCLUDEclause can only be used with empty tables on the active database. The contents of the corresponding tables on the standby and any subscribers will be truncated before the table is added to the replication scheme.
Examples
Add a subscriber to the replication scheme.
ALTER ACTIVE STANDBY PAIR ADD SUBSCRIBER rep4;
Drop two subscribers from the replication scheme.
ALTER ACTIVE STANDBY PAIR DROP SUBCRIBER rep3 DROP SUBSCRIBER rep4;
Alter the store attributes of the rep3 and rep4 databases.
ALTER ACTIVE STANDBY PAIR ALTER STORE rep3 SET PORT 23000 TIMEOUT 180 ALTER STORE rep4 SET PORT 23500 TIMEOUT 180;
Add a table, a sequence and two cache groups to the replication scheme.
ALTER ACTIVE STANDBY PAIR INCLUDE TABLE my.newtab INCLUDE SEQUENCE my.newseq INCLUDE CACHE GROUP my.newcg1, my.newcg2;
Add NetworkOperation clause to active standby pair:
ALTER ACTIVE STANDBY PAIR ADD ROUTE MASTER rep1 ON "machine1" SUBSCRIBER rep2 ON "machine2" MASTERIP "1.1.1.1" PRIORITY 1 SUBSCRIBERIP "2.2.2.2" PRIORITY 1;
ALTER CACHE GROUP
The ALTER CACHE GROUP statement modifies the state, interval and mode of AUTOREFRESH for a cache group.
Updates on the Oracle Database tables can be propagated back to the TimesTen cache group with the use of AUTOREFRESH. AUTOREFRESH can be enabled when the cache group is a user managed cache group or is defined as READONLY with an AUTOREFRESH clause.
Any values or states set by ALTER CACHE GROUP are persistent. They are stored in the database and survive daemon and cache agent restarts.
Required privilege
No privilege is required for the cache group owner.
ALTER ANY CACHE GROUP for another user's cache group.
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
This statement changes the AUTOREFRESH mode of the cache group, which determines which rows are updated during an autorefresh operation. You cannot use the ALTER CACHE GROUP...SET AUTOREFRESH MODE clause in TimesTen Scaleout.
ALTER CACHE GROUP [Owner.]GroupName SET AUTOREFRESH MODE {INCREMENTAL | FULL}
This statement changes the AUTOREFRESH interval on the cache group. You cannot use the ALTER CACHE GROUP...SET AUTOREFRESH INTERVAL clause in TimesTen Scaleout.
ALTER CACHE GROUP [Owner.]GroupName SET AUTOREFRESH INTERVAL IntervalValue {MINUTE[S] | SECOND[S] | MILLISECOND[S]}
This statement alters the AUTOREFRESH state:
ALTER CACHE GROUP [Owner.]GroupName SET AUTOREFRESH STATE {ON | OFF | PAUSED}
Parameters
| Parameter | Description |
|---|---|
|
|
Name assigned to the new cache group. |
|
|
Indicates that changes to the Oracle Database tables should be automatically propagated to TimesTen. |
|
|
Determines which rows in the cache are updated during an autorefresh. If the |
|
|
An integer value that specifies how often If the specified interval is not long enough for an |
|
|
Specifies whether |
|
|
|
|
|
A scheduled |
|
|
A scheduled |
Description
-
A refresh does not occur immediately after issuing
ALTER CACHE GROUP...SET AUTOREFRESH STATE. This statement only changes the state ofAUTOREFRESH. When the transaction that contains theALTER CACHE GROUPstatement is committed, the cache agent is notified to schedule anAUTOREFRESHimmediately, but the commit goes through without waiting for the completion of the refresh. The scheduling of the autorefresh operation is part of the transaction, but the refresh itself is not. -
If you issue an
ALTER CACHE GROUP... SET AUTOREFRESH STATE OFFstatement and there is an autorefresh operation currently running, then:-
If
LockWaitinterval is 0, theALTERstatement fails with a lock timeout error. -
If
LockWaitinterval is nonzero, then the current autorefresh transaction is rolled back, and theALTERstatement continues. This affects all cache groups with the same autorefresh interval.
-
-
Replication cannot occur between cache groups with
AUTOREFRESHand cache groups withoutAUTOREFRESH. -
If the
ALTER CACHE GROUPstatement is part of a transaction that is being replicated, and if the replication scheme has theRETURN TWOSAFEattribute, the transaction may fail. -
You cannot execute the
ALTER CACHE GROUPstatement when performed under the serializable isolation level. An error message is returned when attempted.
See also
ALTER FUNCTION
This statement is not supported in TimesTen Scaleout.
In TimesTen Classic:
The ALTER FUNCTION statement recompiles a standalone stored function. Explicit recompilation eliminates the need for implicit runtime recompilation and prevents associated runtime compilation errors and performance overhead.
To recompile a function that is part of a package, recompile the package using the ALTER PACKAGE statement.
Required privilege
No privilege is required for the PL/SQL function owner.
ALTER ANY PROCEDURE for another user's function.
Usage with TimesTen Scaleout
This statement is not supported with TimesTen Scaleout.
SQL syntax
ALTER FUNCTION [Owner.]FunctionNameCOMPILE [CompilerParametersClause[...]] [REUSE SETTINGS]
Parameters
| Parameter | Description |
|---|---|
|
|
Name of the function to be recompiled. |
|
|
Required keyword that causes recompilation of the function. If the function does not compile successfully, use the |
|
|
Use this optional clause to specify a value for one of the PL/SQL persistent compiler parameters. The PL/SQL persistent compiler parameters are You can specify each parameter once in the statement. If you omit a parameter from this clause and you specify |
|
|
Use this optional clause to prevent TimesTen from dropping and reacquiring compiler switch settings. When you specify |
Description
-
The
ALTER FUNCTIONstatement does not change the declaration or definition of an existing function. To redeclare or redefine a function, use theCREATE FUNCTIONstatement. -
TimesTen first recompiles objects upon which the function depends, if any of those objects are invalid.
-
TimesTen also invalidates any objects that depend on the function, such as functions that call the recompiled function or package bodies that define functions that call the recompiled function.
-
If TimesTen recompiles the function successfully, then the function becomes valid. If recompiling the function results in compilation errors, then TimesTen returns an error and the function remains invalid. Use the
ttIsqlcommandSHOW ERRORSto display compilation errors. -
During recompilation, TimesTen drops all persistent compiler settings, retrieves them again from the session, and stores them at the end of compilation. To avoid this process, specify the
REUSE SETTINGSclause.
See also
ALTER PACKAGE
This statement is not supported in TimesTen Scaleout.
In TimesTen Classic:
The ALTER PACKAGE statement explicitly recompiles a package specification, package body, or both. Explicit recompilation eliminates the need for implicit runtime recompilation and prevents associated runtime compilation errors.
This statement recompiles all package objects together. You cannot use the ALTER PROCEDURE or ALTER FUNCTION statement to individually recompile a procedure or function that is part of a package.
Required privilege
No privilege is required for the package owner.
ALTER ANY PROCEDURE for another user's package.
Usage with TimesTen Scaleout
This statement is not supported with TimesTen Scaleout.
SQL syntax
ALTER PACKAGE [Owner.]PackageNameCOMPILE [PACKAGE|SPECIFICATION|BODY] [CompilerParametersClause[...]] [REUSE SETTINGS]
Parameters
| Parameter | Description |
|---|---|
|
|
Name of the package to be recompiled. |
|
|
Required clause used to force the recompilation of the package specification, package body, or both. |
|
|
Specify
|
|
|
Use this optional clause to specify a value for one of the PL/SQL persistent compiler parameters. The PL/SQL persistent compiler parameters are You can specify each parameter once in the statement. If you omit a parameter from this clause and you specify |
|
|
Use this optional clause to prevent TimesTen from dropping and reacquiring compiler switch settings. When you specify |
Description
-
When you recompile a package specification, TimesTen invalidates local objects that depend on the specification, such as procedures that call procedures or functions in the package. The body of the package also depends on the specification. If you subsequently reference one of these dependent objects without first explicitly recompiling it, then TimesTen recompiles it implicitly at runtime.
-
When you recompile a package body, TimesTen does not invalidate objects that depend on the package specification. TimesTen first recompiles objects upon which the body depends, if any of those objects are invalid. If TimesTen recompiles the body successfully, then the body become valid.
-
When you recompile a package, both the specification and the body are explicitly recompiled. If there are no compilation errors, then the specification and body become valid. If there are compilation errors, then TimesTen returns an error and the package remains invalid.
See also
ALTER PROCEDURE
This statement is not supported in TimesTen Scaleout.
In TimesTen Classic:
The ALTER PROCEDURE statement recompiles a standalone stored procedure. Explicit recompilation eliminates the need for implicit runtime recompilation and prevents associated runtime compilation errors and performance overhead.
To recompile a procedure that is part of a package, recompile the package using the ALTER PACKAGE statement.
Required privilege
No privilege is required for the procedure owner.
ALTER ANY PROCEDURE for another user's procedure.
Usage with TimesTen Scaleout
This statement is not supported with TimesTen Scaleout.
SQL syntax
ALTER PROCEDURE [Owner.]ProcedureNameCOMPILE [CompilerParametersClause[...]] [REUSE SETTINGS]
Parameters
| Parameter | Description |
|---|---|
|
|
Name of the procedure to be recompiled. |
|
|
Required keyword that causes recompilation of the procedure. If the procedure does not compile successfully, use the |
|
|
Use this optional clause to specify a value for one of the PL/SQL persistent compiler parameters. The PL/SQL persistent compiler parameters are You can specify each parameter once in the statement. If you omit a parameter from this clause and you specify |
|
|
Use this optional clause to prevent TimesTen from dropping and reacquiring compiler switch settings. When you specify |
Description
-
The
ALTER PROCEDUREstatement does not change the declaration or definition of an existing procedure. To redeclare or redefine a procedure, use theCREATE PROCEDUREstatement. -
TimesTen first recompiles objects upon which the procedure depends, if any of those objects are invalid.
-
TimesTen also invalidates any objects that depend on the procedure, such as procedures that call the recompiled procedure or package bodies that define procedures that call the recompiled procedure.
-
If TimesTen recompiles the procedure successfully, then the procedure becomes valid. If recompiling the procedure results in compilation errors, then TimesTen returns an error and the procedure remains invalid. Use the
ttIsqlcommandSHOW ERRORSto display compilation errors. -
During recompilation, TimesTen drops all persistent compiler settings, retrieves them again from the session, and stores them at the end of compilation. To avoid this process, specify the
REUSE SETTINGSclause.
Examples
Query the system view USER_PLSQL_OBJECT_SETTINGS to check PLSQL_OPTIMIZE_LEVEL for procedure query_emp. Alter query_emp by changing PLSQL_OPTIMIZE_LEVEL to 3. Verify results.
Command> SELECT PLSQL_OPTIMIZE_LEVEL FROM user_plsql_object_settings WHERE name = 'QUERY_EMP'; < 2 > 1 row found. Command> ALTER PROCEDURE query_emp COMPILE PLSQL_OPTIMIZE_LEVEL = 3; Procedure altered. Command> SELECT PLSQL_OPTIMIZE_LEVEL FROM user_plsql_object_settings WHERE name = 'QUERY_EMP'; < 3 > 1 row found.
See also
ALTER PROFILE
The ALTER PROFILE statement adds, modifies, or removes one or more password parameters in a profile.
Required privilege
ADMIN
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
ALTER PROFILE profile LIMIT password_parameters password_parameters::= [FAILED_LOGIN_ATTEMPTS password_parameter_options] [PASSWORD_LIFE_TIME password_parameter_options] [PASSWORD_REUSE_TIME password_parameter_options] [PASSWORD_REUSE_MAX password_parameter_options] [PASSWORD_LOCK_TIME password_parameter_options] [PASSWORD_GRACE_TIME password_parameter_options] [{PASSWORD_COMPLEXITY_CHECKER|PASSWORD_VERIFY_FUNCTION} password_checker_options] password_parameter_options::= UNLIMITED|DEFAULT|constant password_checker_options::= function|NULL|DEFAULT function::= TT_VERIFY_FUNCTION|TT_STRONG_VERIFY_FUNCTION|TT_STIG_VERIFY_FUNCTION
Parameters
| Parameter | Description |
|---|---|
|
|
Name of the profile. |
|
|
The The password parameters consist of the name of the password parameter and the value (or limit) for the password parameter. This includes the password complexity checker functions. All the parameters (with the exception of If you do not specify a password parameter after the |
|
|
Specifies the number of consecutive failed attempts to connect to the database by a user before that user's account is locked. |
|
|
Specifies the number of days that a user can use the same password for authentication. If you also set a value for |
|
|
These two parameters must be used together.
You must specify a value for both parameters for them to have any effect. Specifically:
|
|
|
Specifies the number of days the user account is locked after the specified number of consecutive failed connection attempts. |
|
|
Specifies the number of days after the grace period begins during which TimesTen issues a warning, but allows the connection to the database. If the password is not changed during the grace period, the password expires. This parameter is associated with the |
|
|
Indicates that there is no limit for the password parameter. If you specify |
|
|
Indicates that you want to omit a limit for the password parameter in this profile. A user that is assigned this profile is subject to the limit defined in the If you specify |
|
|
Indicates the value of the password parameter if you do not specify |
|
|
Indicates if password verification is done on passwords and, if so, the function used for verification. You can specify either the function refers to one of the three supported password complexity checker functions. Specify one of these functions to direct TimesTen to perform password verification. Valid values:
If you do not specify the |
Description
-
Use the
ALTERPROFILEstatement to modify a previously created profile. See "CREATE PROFILE" for information on creating a profile. -
Changes made using the
ALTERPROFILEstatement takes effect the next time any affected user connected to the database. The exception is when you modify thePASSWORD_COMPLEXITY_CHECKERpassword parameter. Password verification is only done on newly created passwords (on the password provided in theIDENTIFIEDBYclause of theCREATEUSERorALTERUSERstatement). Therefore, a user can connect to the database with an old password. See "ALTER the PASSWORD_COMPLEXITY_CHECKER password parameter" for an example. -
You can alter the
DEFAULTprofile. However, you cannot drop theDEFAULTprofile. See "Alter the DEFAULT profile" for an example of altering theDEFAULTprofile. -
You cannot alter the password parameters of the
SYSTEMprofile. This profile is assigned to system users, including the instance administrator. - You can alter the profile to change the password verification that is done on the passwords of users that are assigned the profile. See "About password complexity checker verification" for information on password verification and the password complexity checker verification functions.
Examples
ALTER the PASSWORD_COMPLEXITY_CHECKER password parameter
This example creates the myprofile_alterpw1 profile and specifies TT_VERIFY_FUNCTION for the PASSWORD_COMPLEXITY_CHECKER password parameter. The example then creates the sampleuser_alterpw1 user and assigns the myprofile_alterpw1 profile to the sampleuser_alterpw1 user. The example alters the profile, specifying TT_STIG_VERIFY_FUNCTION for the PASSWORD_COMPLEXITY_CHECKER password parameter. The sampleuser_alterpw1 attempts to connect to the database with the original password. The connection is successful. TimesTen does not perform password verification on old passwords. The example then uses the ALTER USER statement to change the sampleuser_alterpw1 user password to meet the requirements of the TT_STIG_VERIFY_FUNCTION. The ALTER USER statement succeeds and the user's password is changed.
Command> CREATE PROFILE myprofile_alterpw1 LIMIT
PASSWORD_COMPLEXITY_CHECKER TT_VERIFY_FUNCTION;
Profile created.
Command> CREATE USER sampleuser_alterpw1
IDENTIFIED BY "%aabb2L90" PROFILE myprofile_alterpw1;
User created.Alter the myprofile_alterpw1 profile, changing the value of PASSWORD_COMPLEXITY_CHECKER to TT_STIG_VERIFY_FUNCTION. Connect to the database as the sampleuser_alterpw1 user. The connection succeeds.
Command> ALTER PROFILE myprofile_alterpw1 LIMIT
PASSWORD_COMPLEXITY_CHECKER TT_STIG_VERIFY_FUNCTION;
Profile altered.
Command> GRANT CONNECT TO sampleuser_alterpw1;
Command> connect adding "UID=sampleuser_alterpw1;PWD=%aabb2L90" as sampleuser;
Connection successful: DSN=access1;UID=sampleuser_alterpw1;
DataStore=/scratch/sampleuser/mydatabase1;DatabaseCharacterSet=AL32UTF8;
ConnectionCharacterSet=AL32UTF8;PermSize=128;
(Default setting AutoCommit=1)
Alter the sampleuser_alterpw1 user specifying the same password. The ALTER USER statement fails. The newly created password does not meet the requirements of the TT_STIG_VERIFY_FUNCTION function. Alter the sampleuser_alterpw1 again, specifying a password that meets the requirements of the TT_STIG_VERIFY_FUNCTION function. The ALTER USER statement succeeds. See "TT_STIG_VERIFY_FUNCTION" for information on the TT_STIG_VERIFY_FUNCTION function.
Command> ALTER USER sampleuser_alterpw1
IDENTIFIED BY "%aabb2L90";
15186: Password complexity check for the specified password failed
15188: TT-20001: Password length less than 15
The command failed.
Command> ALTER USER sampleuser_alterpw1
IDENTIFIED BY "%aabb2L##mf5Fn!";
User altered.Alter the DEFAULT profile
This example verifies the values of the password parameters in the DEFAULT profile. It then alters the profile with different values. Users that are assigned the DEFAULT profile will inherit the modified values at the user's next connection to the database.
Command> SELECT * FROM dba_profiles WHERE profile='DEFAULT' AND
resource_type='PASSWORD';
< DEFAULT, FAILED_LOGIN_ATTEMPTS, PASSWORD, 10 >
< DEFAULT, PASSWORD_LIFE_TIME, PASSWORD, UNLIMITED >
< DEFAULT, PASSWORD_REUSE_TIME, PASSWORD, UNLIMITED >
< DEFAULT, PASSWORD_REUSE_MAX, PASSWORD, UNLIMITED >
< DEFAULT, PASSWORD_COMPLEXITY_CHECKER, PASSWORD, NULL >
< DEFAULT, PASSWORD_LOCK_TIME, PASSWORD, .0034 >
< DEFAULT, PASSWORD_GRACE_TIME, PASSWORD, UNLIMITED >
7 rows found.
Create the user1 user and do not specify a profile. User1 is assigned the DEFAULT profile. Use the ALTER PROFILE statement to change the value of the FAILED_LOGIN_ATTEMPTS password parameter to 5 and the value of the PASSWORD_LOCK_TIME password parameter to 1 for the DEFAULT profile. Enclose DEFAULT in double quotation marks as DEFAULT is a reserved word. Connect to the database five times as user1 supplying an incorrect password each time. On the sixth attempt, the user1 account is locked.
Command> CREATE USER user1 IDENTIFIED BY user1; User created. Command> GRANT CONNECT TO user1;
Query the dba_users system view to verify that user1 is assigned the DEFAULT profile.
Command> SELECT profile FROM dba_users WHERE username='USER1'; < DEFAULT > 1 row found.
Use the ALTER PROFILE statement to modify the DEFAULT profile.
Command> ALTER PROFILE "DEFAULT" LIMIT
FAILED_LOGIN_ATTEMPTS 5
PASSWORD_LOCK_TIME 1;
Profile altered.
Query the dba_profiles system view to verify the values are changed (represented in bold).
Command> SELECT * FROM dba_profiles WHERE profile='DEFAULT' AND resource_type='PASSWORD'; < DEFAULT, FAILED_LOGIN_ATTEMPTS, PASSWORD, 5 > < DEFAULT, PASSWORD_LIFE_TIME, PASSWORD, UNLIMITED > < DEFAULT, PASSWORD_REUSE_TIME, PASSWORD, UNLIMITED > < DEFAULT, PASSWORD_REUSE_MAX, PASSWORD, UNLIMITED > < DEFAULT, PASSWORD_COMPLEXITY_CHECKER, PASSWORD, NULL > < DEFAULT, PASSWORD_LOCK_TIME, PASSWORD, 1 > < DEFAULT, PASSWORD_GRACE_TIME, PASSWORD, UNLIMITED > 7 rows found.
Attempt to connect to the database as user1. Supply an incorrect password. On the sixth attempt, the user1 account is locked.
Command> connect adding "uid=user1;pwd=user1_test1" as user1; 7001: User authentication failed The command failed. none: Command> connect adding "uid=user1;pwd=user1_test2" as user1; 7001: User authentication failed The command failed. none: Command> connect adding "uid=user1;pwd=user1_test3" as user1; 7001: User authentication failed The command failed. none: Command> connect adding "uid=user1;pwd=user1_test4" as user1; 7001: User authentication failed The command failed. none: Command> connect adding "uid=user1;pwd=user1_test5" as user1; 7001: User authentication failed The command failed. none: Command> connect adding "uid=user1;pwd=user1_test6" as user1; 15179: the account is locked The command failed.
Create a profile then alter the profile
This example creates the profile1 profile and specifies values for the FAILED_LOGIN_ATTEMPTS, the PASSWORD_LIFE_TIME, the PASSWORD_LOCK_TIME, and the PASSWORD_GRACE_TIME password parameters. It then alters the profile1 profile to modify the PASSWORD_REUSE_TIME and the PASSWORD_REUSE_MAX password parameters.
Command> CREATE PROFILE profile1 LIMIT
FAILED_LOGIN_ATTEMPTS 3
PASSWORD_LIFE_TIME 90
PASSWORD_LOCK_TIME 30
PASSWORD_GRACE_TIME 10;
Profile created.
Query the dba_profiles system view to verify the values for the password parameters. Note that the PASSWORD_REUSE_TIME and the PASSWORD_REUSE_MAX password parameters each have a value of DEFAULT (represented in bold). These password parameters were not specified in the CREATE PROFILE definition, so TimesTen assigns a value of DEFAULT to each parameter. The values for these parameters are derived from the values in the DEFAULT profile.
Command> SELECT * FROM dba_profiles WHERE profile = 'PROFILE1' AND
resource_type= 'PASSWORD';
< PROFILE1, FAILED_LOGIN_ATTEMPTS, PASSWORD, 3 >
< PROFILE1, PASSWORD_LIFE_TIME, PASSWORD, 90 >
< PROFILE1, PASSWORD_REUSE_TIME, PASSWORD, DEFAULT >
< PROFILE1, PASSWORD_REUSE_MAX, PASSWORD, DEFAULT >
< PROFILE1, PASSWORD_COMPLEXITY_CHECKER, PASSWORD, DEFAULT >
< PROFILE1, PASSWORD_LOCK_TIME, PASSWORD, 30 >
< PROFILE1, PASSWORD_GRACE_TIME, PASSWORD, 10 >
7 rows found.
Alter the profile1 profile, specifying a value of 20 for the PASSWORD_REUSE_TIME password and a value of 15 for the PASSWORD_REUSE_MAX password parameter (represented in bold). A user assigned this profile can reuse the same password after 20 days if the password has been changed 15 times.
Command> ALTER PROFILE profile1 LIMIT
PASSWORD_REUSE_TIME 20
PASSWORD_REUSE_MAX 15;
Profile altered.
Query the dba_profiles system view to verify the values for the password parameters are changed (represented in bold).
Command> SELECT * FROM dba_profiles WHERE profile = 'PROFILE1' AND
resource_type= 'PASSWORD';
< PROFILE1, FAILED_LOGIN_ATTEMPTS, PASSWORD, 3 >
< PROFILE1, PASSWORD_LIFE_TIME, PASSWORD, 90 >
< PROFILE1, PASSWORD_REUSE_TIME, PASSWORD, 20 >
< PROFILE1, PASSWORD_REUSE_MAX, PASSWORD, 15 >
< PROFILE1, PASSWORD_COMPLEXITY_CHECKER, PASSWORD, DEFAULT >
< PROFILE1, PASSWORD_LOCK_TIME, PASSWORD, 30 >
< PROFILE1, PASSWORD_GRACE_TIME, PASSWORD, 10 >
7 rows found.See also
ALTER REPLICATION
This statement is not supported in TimesTen Scaleout.
In TimesTen Classic:
The ALTER REPLICATION statement adds, alters, or drops replication elements and changes the replication attributes of participating databases involved in a classic replication scheme.
Most ALTER REPLICATION operations are supported only when the replication agent is stopped (ttAdmin -repStop). However, it is possible to dynamically add a subscriber database to a replication scheme while the replication agent is running. See "Altering a Classic Replication Scheme" in Oracle TimesTen In-Memory Database Replication Guide for more information.
Required privilege
ADMIN
Usage with TimesTen Scaleout
This statement is not supported with TimesTen Scaleout.
SQL syntax
The ALTER REPLICATION statement has the syntax:
ALTER REPLICATION [Owner.]ReplicationSchemeName ElementOperation [...] | StoreOperation | NetworkOperation [...]
Specify ElementOperation one or more times:
ADD ELEMENT ElementName { DATASTORE | { TABLE [Owner.]TableName [CheckConflicts] } | SEQUENCE [Owner.]SequenceName } { MASTER | PROPAGATOR } FullStoreName { SUBSCRIBER FullStoreName [,... ] [ReturnServiceAttribute] } [ ... ] { INCLUDE | EXCLUDE } { TABLE [[Owner.]TableName[,...]] | SEQUENCE [[Owner.]SequenceName[,...]] } [,...] ALTER ELEMENT { ElementName | * IN FullStoreName ]} ADD SUBSCRIBER FullStoreName [,...] [ReturnServiceAttribute] | ALTER SUBSCRIBER FullStoreName [,...]| SET [ReturnServiceAttribute] DROP SUBSCRIBER FullStoreName [,... ] ALTER ELEMENT * IN FullStoreName SET { MASTER | PROPAGATOR } FullStoreName ALTER ELEMENT ElementName {SET NAME NewElementName | SET CheckConflicts} ALTER ELEMENT ElementName { INCLUDE | EXCLUDE } { TABLE [Owner.]TableName | SEQUENCE [Owner.]SequenceName }[,...] DROP ELEMENT { ElementName | * IN FullStoreName }
CheckConflicts can only be set when replicating TABLE elements. See "CHECK CONFLICTS" for syntax requirements.
Syntax for ReturnServiceAttribute is:
{ RETURN RECEIPT [BY REQUEST] | NO RETURN }
StoreOperation clauses:
ADD STORE FullStoreName [StoreAttribute [... ]] ALTER STORE FullStoreName SET StoreAttribute [... ]
Syntax for the StoreAttribute is:
DISABLE RETURN {SUBSCRIBER | ALL} NumFailures
RETURN SERVICES {ON | OFF} WHEN [REPLICATION] STOPPED
DURABLE COMMIT {ON | OFF}
RESUME RETURN Milliseconds
LOCAL COMMIT ACTION {NO ACTION | COMMIT}
RETURN WAIT TIME Seconds
COMPRESS TRAFFIC {ON | OFF}
PORT PortNumber
TIMEOUT Seconds
FAILTHRESHOLD Value
CONFLICT REPORTING SUSPEND AT Value
CONFLICT REPORTING RESUME AT Value
TABLE DEFINITION CHECKING {EXACT|RELAXED}
Specify NetworkOperation one or more times:
ADD ROUTE MASTER FullStoreName SUBSCRIBER FullStoreName { { MASTERIP MasterHost | SUBSCRIBERIP SubscriberHost } PRIORITY Priority } [...] DROP ROUTE MASTER FullStoreName SUBSCRIBER FullStoreName { MASTERIP MasterHost | SUBSCRIBERIP SubscriberHost } [...]
Parameters
| Parameter | Description |
|---|---|
|
|
Name assigned to the classic replication scheme. |
|
|
Adds a new element to the existing classic replication scheme. If the element is a |
|
|
Adds a new
If the element is a sequence, |
|
|
Indicates an additional subscriber database. |
|
|
Makes a change to all elements for which This syntax can be used on a set of element names to:
|
|
|
Name of the element to which a subscriber is to be added or dropped. |
|
|
Renames |
|
|
If the element is a sequence, |
|
|
Indicates an alteration to a subscriber database to enable, disable, or change the return receipt service. |
|
|
Check for replication conflicts when simultaneously writing to bidirectionally replicating |
|
|
Compress replicated traffic to reduce the amount of network bandwidth. |
|
|
Suspends conflict resolution reporting.
This clause is valid for table level replication. |
|
|
Resumes conflict resolution reporting.
This clause is valid for table level replication. |
|
|
Set the return service failure policy so that return service blocking is disabled after the number of timeouts specified by If |
|
|
Overrides the |
|
|
Deletes the replication description of all elements for which |
|
|
Deletes the replication description of |
|
|
Indicates that updates should no longer be sent to the specified subscriber database. This operation fails if the classic replication scheme has only one subscriber. |
|
|
The number of log files that can accumulate for a subscriber database. If this value is exceeded, the subscriber is set to the The value 0 means "No Limit." This is the default. See "Setting the transaction log failure threshold" in Oracle TimesTen In-Memory Database Replication Guide for more information. |
|
|
The database, specified as one of the following:
For example, if the database path is This is the database file name specified in the
|
|
|
Specifies the default action to be taken for a
This setting can be overridden for specific transactions by calling the |
|
|
The database on which applications update the specified element. The |
|
|
Specifies that no return service is to be used. This is the default. For details on the use of the return services, see "Using a return service" in Oracle TimesTen In-Memory Database Replication Guide. |
|
|
The TCP/IP port number on which the replication agent on this database listens for connections. If not specified, the replication agent allocates a port number automatically. All TimesTen databases that replicate to each other must use the same port number. |
|
|
The database that receives replicated updates and passes them on to other databases. |
|
|
If return service blocking has been disabled by If |
|
|
Enables the return receipt service, so that applications that commit a transaction to a master database are blocked until the transaction is received by all subscribers.
|
|
|
Sets return services on or off when replication is disabled (stopped or paused state).
|
|
|
Enables the return twosafe service, so that applications that commit a transaction to a master database are blocked until the transaction is committed on all subscribers.
|
|
|
Specifies the number of seconds to wait for return service acknowledgment. The default value is 10 seconds. A value of 0 (zero) means there is no timeout. Your application can override this timeout setting by calling the |
|
|
Sets the given database to be the |
|
|
A database that receives updates from the |
|
|
Specifies type of table definition checking that occurs on the subscriber:
The default is Note: If you use |
|
|
The maximum number of seconds the replication agent waits for a response from remote replication agents. The default is 120 seconds. Note: For large transactions that may cause a delayed response from the remote replication agent, the agent scales the timeout to increasingly larger values, as needed, based on the size of the transaction. This scaling will not occur, and the agent may time out waiting for responses, if you set |
|
|
Adds Can be specified more than once. For |
|
|
Drops Can be specified more than once. For |
|
|
Clause can be specified more than once. Valid for both |
|
|
Variable expressed as an integer from 1 to 99. Denotes the priority of the IP address. Lower integral values have higher priority. An error is returned if multiple addresses with the same priority are specified. Controls the order in which multiple IP addresses are used to establish peer connections. Required syntax of |
Description
-
ALTER ELEMENT DROP SUBSCRIBERdeletes a subscriber for a particular replication element. -
ALTER ELEMENT SET NAMEmay be used to change the name of a replication element when it conflicts with one already defined at another database.SET NAMEdoes not admit the use of* INFullStoreName. TheFullStoreNamemust be the database's file base name. For example, if the database file name isdata.ds0, thendatais the file base name. -
ALTER ELEMENT SET MASTERmay be used to change the master database for replication elements. The* INFullStoreNameoption must be used for theMASTERoperation. That is, a master database must transfer ownership of all of its replication elements, thereby giving up its master role entirely. Typically, this option is used inALTER REPLICATIONstatements requested atSUBSCRIBERdatabases after the failure of a (common)MASTER. -
To transfer ownership of the master elements to the subscriber:
-
Manually drop the replicated elements by executing an
ALTER REPLICATION DROP ELEMENTstatement for each replicated table. -
Use
ALTER REPLICATION ADD ELEMENTto add each table back to the replication scheme, with the newly designatedMASTER/SUBSCRIBERroles.
-
-
ALTER REPLICATION ALTER ELEMENT SET MASTERdoes not automatically retain the old master as a subscriber in the scheme. If this is desired, execute anALTER REPLICATION ALTER ELEMENT ADD SUBSCRIBERstatement.Note:
There is no
ALTER ELEMENT DROP MASTER. Each replication element must have exactly oneMASTERdatabase, and the currently designatedMASTERcannot be deleted from the replication scheme. -
Stop the replication agent before you use the
NetworkOperationclause. -
You cannot alter the following replication schemes with the
ALTER REPLICATIONstatement:-
Any active standby pair. Instead, use
ALTER ACTIVE STANDBY PAIR. -
A Clusterware-managed active standby pair. Instead, perform the tasks described in "Changing the schema" section of the Oracle TimesTen In-Memory Database Replication Guide.
-
Examples
This example sets up a classic replication scheme for an additional table westleads that is updated on database west and replicated to database east.
ALTER REPLICATION r1 ADD ELEMENT e3 TABLE westleads MASTER west ON "westcoast" SUBSCRIBER east ON "eastcoast";
This example adds an additional subscriber (backup) to table westleads.
ALTER REPLICATION r1 ALTER ELEMENT e3 ADD SUBSCRIBER backup ON "backupserver";
This example changes the element name of table westleads from e3 to newelementname.
ALTER REPLICATION r1 ALTER ELEMENT e3 SET NAME newelementname;
This example makes newwest the master for all elements for which west currently is the master.
ALTER REPLICATION r1 ALTER ELEMENT * IN west SET MASTER newwest;
This element changes the port number for east.
ALTER REPLICATION r1 ALTER STORE east ON "eastcoast" SET PORT 22251;
This example adds my.tab1 table to the ds1 database element in my.rep1 replication scheme.
ALTER REPLICATION my.rep1 ALTER ELEMENT ds1 DATASTORE INCLUDE TABLE my.tab1;
This example adds ds1 database to my.rep1 replication scheme. Include my.tab2 table in the database.
ALTER REPLICATION my.rep1 ADD ELEMENT ds1 DATASTORE MASTER rep2 SUBSCRIBER rep1, rep3 INCLUDE TABLE my.tab2;
This example adds ds2 database to a replication scheme but excludes my.tab1 table.
ALTER REPLICATION my.rep1 ADD ELEMENT ds2 DATASTORE MASTER rep2 SUBSCRIBER rep1 EXCLUDE TABLE my.tab1;
Add NetworkOperation clause:
ALTER REPLICATION r ADD ROUTE MASTER rep1 ON "machine1" SUBSCRIBER rep2 ON "machine2" MASTERIP "1.1.1.1" PRIORITY 1 SUBSCRIBERIP "2.2.2.2" PRIORITY 1 MASTERIP "3.3.3.3" PRIORITY 2 SUBSCRIBERIP "4.4.4.4" PRIORITY 2;
Drop NetworkOperation clause:
ALTER REPLICATION r DROP ROUTE MASTER repl ON "machine1" SUBSCRIBER rep2 ON "machine2" MASTERIP "1.1.1.1" SUBSCRIBERIP "2.2.2.2" MASTERIP "3.3.3.3" SUBSCRIBERIP "4.4.4.4";
See also
ALTER ACTIVE STANDBY PAIRCREATE ACTIVE STANDBY PAIRCREATE REPLICATIONDROP ACTIVE STANDBY PAIRDROP REPLICATION
To drop a table from a database, see "Altering a replicated table in a classic replication scheme" in Oracle TimesTen In-Memory Database Replication Guide.
ALTER SEQUENCE
This statement is supported in TimesTen Scaleout only.
Use the ALTER SEQUENCE statement to change the batch value of a sequence.
Required privilege
No privilege is required for the sequence owner.
ALTER ANY SEQUENCE privilege for another user's sequence.
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
ALTER SEQUENCE [Owner.]SequenceName BATCH BatchValue
Parameters
| Parameter | Description |
|---|---|
|
|
Name of the sequence to be altered. |
|
|
Valid with TimesTen Scaleout only. Configures the range of unique sequence values that are stored at each element of the grid. The default value is 10 million. |
Description
-
Use this statement to change the batch value for a sequence in TimesTen Scaleout. The change affects future sequence numbers.
-
This statement cannot be used to alter any other values supported in the
CREATESEQUENCEstatement. In this case, use theDROP SEQUENCEstatement and then create a new sequence with the same name. For example, to change theMINVALUE, drop the sequence and recreate it with the same name and with the desiredMINVALUE.
See "Using sequences" in Oracle TimesTen In-Memory Database Scaleout User's Guide for more information.
Examples
To change the batch value for the sequence:
ALTER SEQUENCE myseq BATCH 2000; Sequence altered
See also
ALTER SESSION
The ALTER SESSION statement changes session parameters dynamically. This overrides the setting of the equivalent connection attribute for the current session, as applicable.
Required privilege
None
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout. However, these parameters are not supported:
-
DDL_REPLICATION_ACTION -
DDL_REPLICATION_LEVEL -
REPLICATION_TRACK
SQL syntax
ALTER SESSION SET
{COMMIT_BUFFER_SIZE_MAX = n |
DDL_REPLICATION_ACTION={'INCLUDE'|'EXCLUDE'} |
DDL_REPLICATION_LEVEL={1|2|3} |
ISOLATION_LEVEL = {SERIALIZABLE | READ COMMITTED} |
NLS_SORT = {BINARY| SortName} |
NLS_LENGTH_SEMANTICS = {BYTE|CHAR} |
NLS_NCHAR_CONV_EXCP = {TRUE|FALSE} |
PLSQL_TIMEOUT = n |
PLSQL_OPTIMIZE_LEVEL = {0|1|2|3}|
PLSQL_CONN_MEM_LIMIT = n |
PLSQL_CCFLAGS = 'name1:value1, name2:value2,..., nameN:valueN' |
PLSQL_SESSION_CACHED_CURSORS = n |
REPLICATION_TRACK = TrackNumber |
} Parameters
| Parameter | Description |
|---|---|
|
|
Changes the maximum size of the commit buffer when a connection is in progress. n is expressed as an integer and represents the maximum size of the commit buffer (in MB). Change takes effect starting with the next transaction. Call the For more information on the commit buffer and transaction reclaim operations, see "Transaction reclaim operations" in the Oracle TimesTen In-Memory Database Operations Guide and "CommitBufferSizeMax" in the Oracle TimesTen In-Memory Database Reference. Note: The equivalent connection attribute is |
|
|
To include a table or sequence in the active standby pair when either is created, set If set to
This attribute is valid only if See "Making DDL changes in an active standby pair" in the Oracle TimesTen In-Memory Database Replication Guide for more information. Note: The equivalent connection attribute is |
|
|
Indicates whether DDL is replicated across all databases in an active standby pair. The value can be one of the following:
See "Making DDL changes in an active standby pair" in the Oracle TimesTen In-Memory Database Replication Guide for more information. Note: The equivalent connection attribute is |
|
|
Sets isolation level. Change takes effect starting with the next transaction. For a descriptions of the isolation levels, see "Transaction isolation levels" in the Oracle TimesTen In-Memory Database Operations Guide. Note: The equivalent connection attribute is |
|
|
Indicates which collation sequence to use for linguistic comparisons. Append If you do not specify For a complete list of supported values for For more information on case-insensitive or accent-insensitive sorting, see "Case-insensitive and accent-insensitive linguistic sorts" in Oracle TimesTen In-Memory Database Operations Guide. |
|
|
Sets the default length semantics configuration. For more information on length semantics, see "Length semantics and data storage" in Oracle TimesTen In-Memory Database Operations Guide. |
|
|
Determines whether an error should be reported when there is data loss during an implicit or explicit character type conversion between |
|
|
Controls how long PL/SQL procedures run before being automatically terminated. When you modify this value, the new value impacts PL/SQL program units that are currently running as well as any other program units subsequently executed in the same connection. See "Choose SQL and PL/SQL timeout values" in the Oracle TimesTen In-Memory Database Operations Guide for information on setting timeout values. |
|
|
Specifies the optimization level used to compile PL/SQL library units. The higher the setting, the more effort the compiler makes to optimize PL/SQL library units. Possible values are 0, 1, 2 or 3. The default is 2. For more information, see "PLSQL_OPTIMIZE_LEVEL" in Oracle TimesTen In-Memory Database Reference. |
|
|
Specifies the maximum amount of process heap memory that PL/SQL can use for this connection, where For more information, see "PLSQL_CONN_MEM_LIMIT" in Oracle TimesTen In-Memory Database Reference. |
|
|
Specifies inquiry directives to control conditional compilation of PL/SQL units, which enables you to customize the functionality of a PL/SQL program depending on conditions that are checked. For example, to activate debugging features: PLSQL_CCFLAGS = 'DEBUG:TRUE' |
|
|
Specifies the maximum number of session cursors to cache. The default is 50. The range of values is 1 to 65535. The |
|
|
When managing track-based parallel replication, you can assign a connection to a replication track. All transactions issued by the connection are assigned to this track, unless the track is altered. If the number specified is for a non-existent replication track You cannot change tracks in the middle of a transaction unless all preceding operations have been read operations. For more information, see "Specifying replication tracks within an automatic parallel replication environment" in Oracle TimesTen In-Memory Database Replication Guide. The equivalent connection attribute is |
Description
-
The
ALTER SESSIONstatement affects commands that are subsequently executed by the session.ALTERSESSIONdoes not do an implicit commit. -
In cases of client failover, if an
ALTERSESSIONstatement is issued in the failed connection, the setting is not seen or carried over to the new connection. You must re-issue theALTERSESSIONstatement and re-specify the value for that parameter. For more information on client failover, in TimesTen Classic, see "Using automatic client failover" in the Oracle TimesTen In-Memory Database Operations Guide and, in TimesTen Scaleout, see "Client connection failover" in the Oracle TimesTen In-Memory Database Scaleout User's Guide. -
Operations involving character comparisons support linguistic sensitive collating sequences. Case-insensitive sorts may affect
DISTINCTvalue interpretation. -
Implicit and explicit conversions between
CHARandNCHARare supported. -
You can use the SQL string functions with the supported character sets. For example,
UPPERandLOWERfunctions support non-ASCIICHARandVARCHAR2characters as well asNCHARandNVARCHAR2characters. -
Choice of character set could have an impact on memory consumption for
CHARandVARCHAR2column data. -
The character sets of all databases involved in a replication scheme must match.
-
To add an existing table to an active standby pair, set
DDL_REPLICATION_LEVELto 2 or greater andDDL_REPLICATION_ACTIONtoINCLUDE. Alternatively, you can use theALTER ACTIVE STANDBY PAIR ... INCLUDE TABLEstatement ifDDL_REPLICATION_ACTIONis set toEXCLUDE. In this case, the table must be empty and present on all databases before executing theALTER ACTIVE STANDBY PAIR ... INCLUDE TABLEstatement as the table contents will be truncated when this statement is executed. -
To add an existing sequence or view to an active standby pair, set
DDL_REPLICATION_LEVELto 3. To include the sequence in the replication scheme,DDL_REPLICATION_ACTIONmust be set toINCLUDE. This does not apply to materialized views. -
Objects are replicated only when the receiving database is of a TimesTen release that supports that level of replication, and is configured for an active standby pair replication scheme. For example, replication of sequences (requiring
DDL_REPLICATION_LEVEL=3) to a database release prior to 11.2.2.7.0 is not supported. The receiving database must be of at least release 11.2.1.8.0 for replication of objects supported byDDL_REPLICATION_LEVEL=2.
Examples
Use the ALTER SESSION statement to change COMMIT_BUFFER_SIZE_MAX to 500 MB. First, call ttConfiguration to display the current connection setting. Use the ALTER SESSION statement to change the COMMIT_BUFFER_SIZE_MAX setting to 500. Call ttConfiguration to display the new setting.
Command> CALL ttConfiguration ('CommitBufferSizeMax');
< CommitBufferSizeMax, 0 >
1 row found.
Command> ALTER SESSION SET COMMIT_BUFFER_SIZE_MAX = 500;
Session altered.
Command> CALL ttConfiguration ('CommitBufferSizeMax');
< CommitBufferSizeMax, 500 >
1 row found.
Use the ALTER SESSION statement to change PLSQL_TIMEOUT to 60 seconds. Use a second ALTER SESSION statement to change PLSQL_OPTIMIZE_LEVEL to 3. Then call ttConfiguration to display the new values.
Command> ALTER SESSION SET PLSQL_TIMEOUT = 60; Session altered. Command> ALTER SESSION SET PLSQL_OPTIMIZE_LEVEL = 3; Session altered. Command> CALL TTCONFIGURATION (); < CkptFrequency, 600 > < CkptLogVolume, 0 > < CkptRate, 0 > ... < PLSQL_OPTIMIZE_LEVEL, 3 > < PLSQL_TIMEOUT, 60 > ... 47 rows found.
In this example, set PLSQL_TIMEOUT to 20 seconds. Attempt to execute a program that loops indefinitely. In 20 seconds, execution is terminated and an error is returned.
Command> ALTER SESSION SET PLSQL_TIMEOUT = 20;
Command> DECLARE v_timeout NUMBER;
BEGIN
LOOP
v_timeout :=0;
EXIT WHEN v_timeout < 0;
END LOOP;
END;
/
8509: PL/SQL execution terminated; PLSQL_TIMEOUT exceeded
The following example uses the ALTER SESSION statement to change the NLS_SORT setting from BINARY to BINARY_CI to BINARY_AI. The database and connection character sets are WE8ISO8859P1.
Command> connect "dsn=cs;ConnectionCharacterSet=WE8ISO8859P1";
Connection successful: DSN=cs;UID=user;DataStore=/datastore/user/cs;
DatabaseCharacterSet=WE8ISO8859P1;
ConnectionCharacterSet=WE8ISO8859P1;PermSize=32;
(Default setting AutoCommit=1)
Command> -- Create the Table
Command> CREATE TABLE collatingdemo (letter VARCHAR2 (10));
Command> -- Insert values
Command> INSERT INTO collatingdemo VALUES ('a');
1 row inserted.
Command> INSERT INTO collatingdemo VALUES ('A');
1 row inserted.
Command> INSERT INTO collatingdemo VALUES ('Y');
1 row inserted.
Command> INSERT INTO collatingdemo VALUES ('ä');
1 row inserted.
Command> -- SELECT
Command> SELECT * FROM collatingdemo;
< a >
< A >
< Y >
< ä >
4 rows found.
Command> --SELECT with ORDER BY
Command> SELECT * FROM collatingdemo ORDER BY letter;
< A >
< Y >
< a >
< ä >
4 rows found.
Command>-- set NLS_SORT to BINARY_CI and SELECT
Command> ALTER SESSION SET NLS_SORT = BINARY_CI;
Command> SELECT * FROM collatingdemo ORDER BY letter;
< a >
< A >
< Y >
< Ä >
< ä >
4 rows found.
Command> -- Set NLS_SORT to BINARY_AI and SELECT
Command> ALTER SESSION SET NLS_SORT = BINARY_AI;
Command> SELECT * FROM collatingdemo ORDER BY letter;
< ä >
< a >
< A >
< Y >
4 rows found.
The following example enables automatic parallel replication with disabled commit dependencies. It uses the ALTER SESSION statement to change the replication track number to 5 for the current connection. To enable automatic parallel replication with disabled commit dependencies for replication schemes, set ReplicationApplyOrdering to 2. Then, always set REPLICATION_TRACK to a number less than or equal to ReplicationParallelism. For example, the ReplicationParallelism connection attribute could be set to 6, which is higher than the value of 5 set for REPLICATION_TRACK.
Command> ALTER SESSION SET REPLICATION_TRACK = 5; Session altered.
The following example enables replication of adding and dropping columns, tables, synonyms and indexes by setting the following on the active database in an alter standby replication pair: DDL_REPLICATON_LEVEL set to 2 and DDLReplicationAction set to 'INCLUDE'.
Command > ALTER SESSION SET DDL_REPLICATION_LEVEL=2; Session altered. Command > ALTER SESSION SET DDL_REPLICATION_ACTION='INCLUDE'; Session altered.
Note:
The equivalent connection attributes for DDL_REPLICATION_LEVEL and DDL_REPLICATION_ACTION are DDLReplicationLevel and DDLReplicationAction, respectively.
ALTER TABLE
The ALTER TABLE statement changes an existing table definition.
The ALTER TABLE statement is supported in TimesTen Scaleout and in TimesTen Classic. However, there are differences in syntax and semantics. For simplicity, the supported syntax, parameters, description (semantics), and examples for TimesTen Scaleout and for TimesTen Classic are separated into the usage with TimesTen Scaleout and the usage with TimesTen Classic. While there is repetition in the usages, it is presented this way in order to allow you to progress from syntax to parameters to semantics to examples for each usage.
Review the required privilege section and then see:
Required privilege
No privilege is required for the table owner.
ALTER ANY TABLE for another user's table.
For ALTER TABLE...ADD FOREIGN KEY, the owner of the altered table must have the REFERENCES privilege on the table referenced by the foreign key clause.
After reviewing this section, see:
ALTER TABLE: Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout. Column-based compression and aging are not supported.
See:
-
Parameters for ALTER TABLE ADD CONSTRAINT PRIMARY KEY: TimesTen Scaleout
-
Parameters for ALTER TABLE ADD UNIQUE CONSTRAINT: TimesTen Scaleout
- Description for ALTER TABLE ADD PRIMARY KEY: TimesTen Scaleout
-
Examples: Add primary key constraint using global indexes in TimesTen Scaleout
-
Examples: Add unique constraint using global indexes in TimesTen Scaleout
ALTER TABLE: Usage with TimesTen Classic
See:
SQL syntax for ALTER TABLE: TimesTen Scaleout
To change the distribution key in TimesTen Scaleout:
ALTER TABLE [Owner.]TableName DistributionClause
To add a primary key constraint and optionally specify a global or local index:
Note: The (CreateIndexStmt) is the clause used to represent the TimesTen CREATE INDEX statement. The parentheses ( ) are required. You must create a unique index as that is the requirement for a primary key constraint. See "CREATE INDEX" for details.
ALTER TABLE [Owner.]TableName ADD CONSTRAINT ConstraintName
PRIMARY KEY (ColumnName [,... ]) [(UsingIndexClause2)]
UsingIndexClause2::= USING INDEX {GLOBAL|LOCAL} [USE HASH INDEX PAGES=RowPages|CURRENT]|
USING INDEX (CreateIndexStmt)
Note:
You cannot useALTER TABLE to drop a primary key constraint. To drop the constraint, you must drop and recreate the table.
To add a unique constraint on a column and optionally specify a global or local index:
Note: The (CreateIndexStmt) is the clause used to represent the TimesTen CREATE INDEX statement. The parentheses ( ) are required. You must create a unique index as that is the requirement for a unique constraint. See CREATE INDEX for details.
ALTER TABLE Owner.]TableName
ADD UNIQUE (ColumnName)
[UsingIndexClause1]
UsingIndexClause1::= USING INDEX {GLOBAL | LOCAL}| USING INDEX (CreateIndexStmt)
To add one column:
ALTER TABLE [Owner.]TableName ADD [COLUMN] ColumnName ColumnDataType [DEFAULT DefaultVal] [[NOT] INLINE] [UNIQUE] [NULL] [COMPRESS (CompressColumns [,...])]
To add multiple columns:
ALTER TABLE [Owner.]TableName ADD (ColumnName ColumnDataType [DEFAULT DefaultVal] [[NOT] INLINE] [UNIQUE] [NULL] [,... ] )
To add a NOT NULL column (note that the DEFAULT clause is required):
ALTER TABLE [Owner.]TableName ADD [COLUMN] ColumnName ColumnDataType NOT NULL [ENABLE] DEFAULT DefaultVal [[NOT] INLINE] [UNIQUE]
To add multiple NOT NULL columns (note that the DEFAULT clause is required):
ALTER TABLE [Owner.]TableName ADD (ColumnName ColumnDataType NOT NULL [ENABLE] DEFAULT DefaultVal [[NOT] INLINE] [UNIQUE] [,...])
To remove columns.
ALTER TABLE [Owner.]TableName DROP {[COLUMN] ColumnName | (ColumnName [,... ] )}
To add a foreign key and optionally add ON DELETE CASCADE:
ALTER TABLE [Owner.]TableName ADD [CONSTRAINT ForeignKeyName] FOREIGN KEY (ColumnName [,...]) REFERENCES RefTableName [(ColumnName [,...])] [ON DELETE CASCADE]
To remove a foreign key:
ALTER TABLE [Owner.]TableName DROP CONSTRAINT ForeignKeyName
To resize a hash index:
ALTER TABLE [Owner.]TableName SET PAGES = RowPages | CURRENT
To change the primary key to use a hash index:
ALTER TABLE [Owner.]TableName USE HASH INDEX PAGES = RowPages | CURRENT
To change the primary key to use a range index with the USE RANGE INDEX clause:
ALTER TABLE [Owner.]TableName USE RANGE INDEX
To change the default value of a column:
ALTER TABLE [Owner.]TableName MODIFY (ColumnName DEFAULT DefaultVal)
To drop a unique constraint on a column:
ALTER TABLE Owner.]TableName DROP UNIQUE (ColumnName)
To remove the default value of a column that is nullable, by changing it to NULL:
ALTER TABLE [Owner.]TableName MODIFY (ColumnName DEFAULT NULL)
Parameters for ALTER TABLE ADD CONSTRAINT PRIMARY KEY: TimesTen Scaleout
| Parameter | Description |
|---|---|
ALTER TABLE [Owner.]TableName |
Start of ALTER TABLE statement. Name of table required. Owner i optional.
|
ADD CONSTRAINT ConstraintName PRIMARY KEY |
Clause indicating that the table is to be altered by adding a primary key constraint. ConstraintName is the name of the constraint. Once you add the primary key constraint, you cannot drop it. You must drop the table.
|
(ColumnName [,…]) |
(ColumnName) is required and specifies the column(s) to use for the primary key constraint.
|
[UsingIndexClause2] |
UsingIndexClause2 is optional and is described in the remainder of this table. You cannot specify two USING INDEX clauses in the ALTER TABLE definition.
|
USING INDEX {GLOBAL|LOCAL} |
Part of [UsingIndexClause2]: If specified, indicates if a global or local index is to be created for the primary key.
|
USE HASH INDEX PAGES = RowPages|CURRENT |
Part of the USING INDEX {GLOBAL|LOCAL} clause and is optional. If specified, indicates a unique hash index is to be created for the primary key. If not specified, a unique range index is created. Can be used for both global and local indexes.
The If you specify The value for If you specify TimesTen recommends that you do not specify |
USING INDEX (CreateIndexStmt) |
Part of the [UsingIndexClause2] clause. When this USING INDEX clause is specified, the (CreateIndexStmt) clause indicates that you want to define the index according to the TimesTen CREATE INDEX statement. The parentheses ( ) are required. You must create a unique index as that is the requirement for a primary key constraint. See "CREATE INDEX" for information on the CREATE INDEX statement.
|
Parameters for ALTER TABLE ADD UNIQUE CONSTRAINT: TimesTen Scaleout
| Parameter | Description |
|---|---|
ALTER TABLE [Owner.]TableName |
Start of ALTER TABLE statement. Name of table required. Owner is optional.
|
ADD UNIQUE (ColumnName [,…])
|
Clause indicating that the table is to be altered by adding a unique constraint. (ColumnName) is required and specifies the column(s) to be used for the unique constraint.
|
[UsingIndexClause1] |
UsingIndexClause1 is optional and is described in the remainder of this table. You cannot specify two USING INDEX clauses in the ALTER TABLE definition. This clause enables you to define a global or local index for the PRIMARY KEY |
USING INDEX {GLOBAL|LOCAL} |
Part of [UsingIndexClause1]. If specified, indicates if a global or local index is to be created for the unique constraint.
|
USING INDEX (CreateIndexStmt) |
Part of the [UsingIndexClause1] clause. When this USING INDEX clause is specified, the (CreateIndexStmt) clause indicates that you want to define the index according to the TimesTen CREATE INDEX statement. The parentheses ( ) are required. You must create a unique index as that is the requirement for a unique constraint. See "CREATE INDEX" for information on the CREATE INDEX statement.
|
Additional parameters for ALTER TABLE: TimesTen Scaleout
| Parameter | Description |
|---|---|
|
|
Identifies the table to be altered. |
|
|
See "CREATE TABLE" for information on syntax. |
|
|
Specifies that in the column |
|
|
Specifies that an attribute of a given column is to be changed to a new value. |
|
|
Specifies that the column has a default value, Altering the default value of a column has no impact on existing rows. Note: To add a |
|
|
Name of the column participating in the |
|
|
Type of the column to be added. Some types require additional parameters. See "Data Types" for the data types that can be specified. |
|
|
If you add a column, you can specify |
|
|
By default, variable-length columns whose declared column length is > 128 bytes are stored out of line. Variable-length columns whose declared column length is <= 128 bytes are stored inline. The default behavior can be overridden during table creation through the use of the |
|
|
Specifies that a foreign key is to be dropped. Optionally specifies that an added foreign key is named by the user. |
DROP UNIQUE (ColumnName)
|
Indicates that unique constraint is to dropped. ColumnName is the name of the constraint.
|
|
|
Name of the foreign key to be added or dropped. All foreign keys are assigned a default name by the system if the name was not specified by the user. Either the user-provided name or system name can be specified in the |
|
|
Specifies that a foreign key is to be added. |
|
|
Specifies that the foreign key references another table. |
|
|
The name of the table that the foreign key references. |
|
|
Enables the |
|
|
Changes primary key to use a hash index. If the primary key already uses a hash index, then this clause is equivalent to the |
|
|
Changes primary key to use a range index. If the primary key already uses a range index, TimesTen ignores this clause. |
|
|
Resizes the hash index to reflect the expected number of pages in the table. If you specify The value for TimesTen recommends that you do not specify If your estimate is too small, performance may be degraded. See "Column definition: TimesTen Scaleout" for more information on hash indexes. |
Description for ALTER TABLE ADD PRIMARY KEY: TimesTen Scaleout
PRIMARY KEY clause in your ALTER TABLE definition. This clause enables you to specify a global or local index for the primary key constraint.
-
The
USINGINDEX {GLOBAL | LOCAL}clause is one option that enables you to specify a global or local index for the primary key constraint. You must specify theGLOBALor theLOCALkeyword. You can optionally specify theUSEHASHINDEXclause after theUSINGINDEX {GLOBAL | LOCAL}clause if you want to define a hash index. - The
USING INDEX (CreateIndexStmt)clause is your other option for specifying a global or local index. The(CreateIndexStmt)clause indicates that you want to define the index according to the TimesTenCREATEINDEXstatement. The parentheses( )are required. You must create a unique index as that is the requirement for a primary key constraint. See "CREATE INDEX" for information on theCREATEINDEXstatement.
Note:
You cannot use both theUSING INDEX {GLOBAL | LOCAL} and the USING INDEX (CreateIndexStmt) in the ALTER TABLE definition. Specify one clause or the other or specify neither.
See "CREATE INDEX" for information on global and local indexes and their use in TimesTen Scaleout.
Description for ALTER TABLE ADD UNIQUE: TimesTen Scaleout
UNIQUE clause in your ALTER TABLE definition. This clause enables you to specify a global or local index for the unique constraint.
-
The
USINGINDEX {GLOBAL | LOCAL}clause is one option that enables you to specify a global or local index for the primary key constraint. You must specify theGLOBALor theLOCALkeyword. - The
USING INDEX (CreateIndexStmt)clause is your other option for specifying a global or local index. The(CreateIndexStmt)clause indicates that you want to define the index according to the TimesTenCREATEINDEXstatement. The parentheses( )are required. You must create a unique index as that is the requirement for a unique constraint. See "CREATE INDEX" for information on theCREATEINDEXstatement.
Note:
You cannot use both theUSING INDEX {GLOBAL | LOCAL} and the USING INDEX (CreateIndexStmt) in the ALTER TABLE definition. Specify one clause or the other or specify neither.
See CREATE INDEX for information on global and local indexes and their use in TimesTen Scaleout.
Additional ALTER TABLE information: TimesTen Scaleout
-
You can alter tables to change defaults or add and drop columns and constraints. However, you cannot change the distribution scheme unless the table is empty. In addition, you cannot drop a constraint that is named in the
DISTRIBUTEBYREFERENCEclause. See "CREATE TABLE" for information on the distribution schemes. See "Altering tables" in Oracle TimesTen In-Memory Database Scaleout User's Guide for more information. -
The
ALTER TABLEstatement cannot be used to alter a temporary table. -
The
ALTER TABLE ADD [COLUMN]ColumnNamestatement adds one or more new columns to an existing table. When you add one or more columns, the new columns are added to the end of all existing rows of the table in one new partition. -
Columns referenced by materialized views cannot be dropped.
-
You cannot use the
ALTERTABLEstatement to add a column, drop a column, or add a constraint for cache group tables. -
Only one partition is added to the table per statement regardless of the number of columns added.
-
You can
ALTERa table to add aNOTNULLcolumn with a default value. TheDEFAULTclause is required. Restrictions include:-
You cannot use the column as a primary key column. Specifically, you cannot specify the column in the statement:
ALTERTABLEADDConstraintNamePRIMARYKEY(ColumnName[,...]).
-
-
NULLis the initial value for all added columns, unless a default value is specified for the new column. -
The total number of columns in the table cannot exceed 1000. In addition, the total number of partitions in a table cannot exceed 1000, one of which is used by TimesTen.
-
Do not specify the
ADD CONSTRAINT ... PRIMARY KEYclause on a global temporary table. -
As the result of an
ALTER TABLE ADDstatement, an additional read occurs for each new partition during queries. Therefore, altered tables may have slightly degraded performance. The performance can only by restored by dropping and recreating the table, or by using thettMigrate create -c-relaxedUpgradecommand, and restoring the table using thettRestore -r-relaxedUpgradecommand. Dropping the added column does not recover the lost performance or decrease the number of partitions. -
When you use the
ALTER TABLE DROPstatement to remove one or more columns from an existing table, dropped columns are removed from all current rows of the table. Subsequent SQL statements must not attempt to make any use of the dropped columns. You cannot drop columns that are in the table's primary key. You cannot drop columns that are in any of the table's foreign keys until you have dropped all foreign keys. You cannot drop columns that are indexed until all indexes on the column have been dropped.ALTER TABLEcannot be used to drop all of the columns of a table. UseDROP TABLEinstead. -
When a column is dropped from a table, all commands referencing that table need to be recompiled. An error may result at recompilation time if a dropped column was referenced. The application must re-prepare those commands, and rebuild any parameters and result columns. When a column is added to a table, the commands that contain a
SELECT *statement are invalidated. Only these commands must be re-prepared. All other commands continue to work as expected. -
When you drop a column, the column space is not freed.
-
When you add a
UNIQUEconstraint, there is overhead incurred (in terms of additional space and additional time). This is because an index is created to maintain theUNIQUEconstraint. You cannot use theDROP INDEXstatement to drop an index used to maintain theUNIQUEconstraint. -
A
UNIQUEconstraint and its associated index cannot be dropped if it is being used as a unique index on a replicated table. -
Use
ALTER TABLE...USE RANGE INDEXif your application performs range queries over a table's primary key. -
Use
ALTER TABLE...USE HASH INDEXif your application performs exact match lookups on a table's primary key. -
An error is generated if a table has no primary key and either the
USE HASH INDEXclause or theUSE RANGE INDEXclause is specified. -
If
ON DELETE CASCADEis specified on a foreign key constraint for a child table, a user can delete rows from a parent table for which the user has theDELETEprivilege without requiring explicitDELETEprivilege on the child table. -
To change the
ON DELETE CASCADEtriggered action, drop then redefine the foreign key constraint. -
ON DELETE CASCADEis supported on detail tables of a materialized view. If you have a materialized view defined over a child table, a deletion from the parent table causes cascaded deletes in the child table. This, in turn, triggers changes in the materialized view. -
The total number of rows reported by the
DELETEstatement does not include rows deleted from child tables as a result of theON DELETE CASCADEaction. -
For
ON DELETE CASCADE, since different paths may lead from a parent table to a child table, the following rule is enforced: -
Either all paths from a parent table to a child table are "delete" paths or all paths from a parent table to a child table are "do not delete" paths.
-
Specify
ON DELETE CASCADEon all child tables on the "delete" path. -
This rule does not apply to paths from one parent to different children or from different parents to the same child.
-
-
For
ON DELETE CASCADE, a second rule is also enforced: -
If a table is reached by a "delete" path, then all its children are also reached by a "delete" path.
-
The
ALTER TABLE ADD/DROP CONSTRAINTstatement has the following restrictions:-
When a foreign key is dropped, TimesTen also drops the index associated with the foreign key. Attempting to drop an index associated with a foreign key using the regular
DROP INDEXstatement results in an error. -
Foreign keys cannot be added or dropped on views or temporary tables.
-
You cannot use
ALTER TABLEto drop a primary key constraint. You would have to drop and recreate the table in order to drop the constraint.
-
Examples: Add primary key constraint using global indexes in TimesTen Scaleout
These examples show various uses of the syntax for using global indexes with ALTER TABLE ADD PRIMARY KEY.
USING INDEX GLOBAL clause. Drop the table.Command> CREATE TABLE mytab1 (c TT_INTEGER NOT NULL, b TT_INTEGER NOT NULL,
a TT_INTEGER NOT NULL) DISTRIBUTE BY HASH (a,b);
Command> ALTER TABLE mytab1 ADD CONSTRAINT pk PRIMARY KEY (c,b) USING INDEX GLOBAL;
Command> indexes mytab1;
Indexes on table SAMPLEUSER.MYTAB1:
PK: global unique range index on columns:
C
B
1 index found.
1 index found on 1 table.
Command> DROP TABLE mytab1;
Create a table. Alter the table adding a primary key constraint. Specify the USING INDEX GLOBAL with the USE HASH INDEX PAGES clause. Drop the table.
Command> CREATE TABLE mytab1 (c TT_INTEGER NOT NULL, b TT_INTEGER NOT NULL,
a TT_INTEGER NOT NULL) DISTRIBUTE BY HASH (a,b);
Command> ALTER TABLE mytab1 ADD CONSTRAINT pk PRIMARY KEY (c,b)
USING INDEX GLOBAL USE HASH INDEX PAGES =200;
Command> INDEXES mytab1;
Indexes on table SAMPLEUSER.MYTAB1:
PK: global unique hash index on columns:
C
B
1 index found.
1 index found on 1 table.
Command> DROP TABLE mytab1;Create a table. Alter the table adding a primary key constraint. Specify the USING INDEX (CreateIndexStmt) clause. The (CreateIndexStmt) clause is the TimesTen CREATE INDEX statement. See "CREATE INDEX" for information on this statement.
Command> CREATE TABLE mytab1 (c TT_INTEGER NOT NULL, b TT_INTEGER NOT NULL,
a TT_INTEGER NOT NULL) DISTRIBUTE BY HASH (a,b);
Command> ALTER TABLE mytab1 ADD CONSTRAINT pk PRIMARY KEY (c,b)
USING INDEX (CREATE GLOBAL UNIQUE HASH INDEX myglobalix ON mytab1 (c,b) PAGES =200);
Command> indexes mytab1;
Indexes on table SAMPLEUSER.MYTAB1:
MYGLOBALIX: global unique hash index on columns:
C
B
1 index found.
1 index found on 1 table.
Command> DROP TABLE mytab1;USING INDEX GLOBAL|LOCAL clause with the USING INDEX (CreateIndexStmt) clause.Command> CREATE TABLE mytab1 (c TT_INTEGER NOT NULL, b TT_INTEGER NOT NULL,
a TT_INTEGER NOT NULL) DISTRIBUTE BY HASH (a,b);
Command> ALTER TABLE mytab1 ADD CONSTRAINT pk PRIMARY KEY (c,b)
USING INDEX GLOBAL USE HASH INDEX PAGES = 200
USING INDEX (CREATE GLOBAL UNIQUE HASH INDEX myglobalix ON mytab1 (c,b) PAGES =200);
1001: Syntax error in SQL statement before or at: "USING", character position: 102
...USING INDEX GLOBAL USE HASH INDEX PAGES = 200 USING INDEX (CREATE G...
^^^^^
The command failed.
Examples: Add unique constraint using global indexes in TimesTen Scaleout
These examples show various uses of the syntax for using global indexes with ALTER TABLE ADD UNIQUE CONSTRAINT.
Create a table. Alter the table adding a unique constraint. Drop the table. Create the table again adding a unique constraint and specifying the USING INDEX GLOBAL clause.
Command> CREATE TABLE mytab1 (c TT_INTEGER NOT NULL, b TT_INTEGER NOT NULL,
a TT_INTEGER NOT NULL) DISTRIBUTE BY HASH (a,b);
Command> ALTER TABLE mytab1 ADD UNIQUE (a);
Command> indexes mytab1;
Indexes on table SAMPLEUSER.MYTAB1:
TTUNIQUE_6E6: unique range index on columns:
A
1 index found.
1 index found on 1 table.
Command> DROP TABLE mytab1;
Command> CREATE TABLE mytab1 (c TT_INTEGER NOT NULL, b TT_INTEGER NOT NULL,
a TT_INTEGER NOT NULL) DISTRIBUTE BY HASH (a,b);
Command> ALTER TABLE mytab1 ADD UNIQUE (a) USING INDEX GLOBAL;
Command> indexes mytab1;
Indexes on table SAMPLEUSER.MYTAB1:
$GUA8C5B4ECE6D8: global unique range index on columns:
A
1 index found.
1 index found on 1 table.
Command> DROP TABLE mytab1;Create a table. Alter the table adding a unique constraint and use the USING INDEX (CreateIndexStmt) clause to create a local unique index. Alter the table a second time adding another unique constaint. Use the USING INDEX (CreateIndexStmt) clause to create a global unique index.
Command> CREATE TABLE mytab1 (c TT_INTEGER NOT NULL, b TT_INTEGER NOT NULL,
a TT_INTEGER NOT NULL) DISTRIBUTE BY HASH (a,b);
Command> ALTER TABLE mytab1 ADD UNIQUE (b) USING INDEX (CREATE UNIQUE INDEX myuniqueidxB ON mytab1 (b));
Command> indexes mytab1;
Indexes on table SAMPLEUSER.MYTAB1:
MYUNIQUEIDXB: unique range index on columns:
B
1 index found.
1 index found on 1 table.
Command> ALTER TABLE mytab1 ADD UNIQUE (c) USING INDEX (CREATE GLOBAL UNIQUE INDEX myuniqueidxC ON mytab1 (c));
Command> indexes mytab1;
Indexes on table SAMPLEUSER.MYTAB1:
MYUNIQUEIDXB: unique range index on columns:
B
MYUNIQUEIDXC: global unique range index on columns:
C
2 indexes found.
2 indexes found on 1 table.
Command> DROP TABLE mytab1;Additional examples for ALTER TABLE: TimesTen Scaleout
Table 6-6 shows the rules associated with altering tables. Supporting examples follow.
Table 6-6 ALTER TABLE rules
| ALTER statement | Comment |
|---|---|
ALTER TABLE t1 ADD CONSTRAINT c1 PRIMARY KEY (p); |
The primary key constraint is added to the table. The distribution key is not changed. |
CREATE TABLE t1 (c1 NUMBER, c2 VARCHAR2 (10)); ALTER TABLE t1 DISTRIBUTE BY HASH (c1); |
The operation succeeds if the table is empty. If the table is not empty, the operation fails because the distribution key cannot be changed on tables that are not empty. |
ALTER TABLE t1 ADD CONSTRAINT c1 FOREIGN KEY (f1)REFERENCES t2 (c2); |
The operation succeeds. The distribution of the |
CREATE TABLE t1...CONSTRAINT fk1... DISTRIBUTE BY REFERENCE(fk1); ALTER TABLE t1 DROP CONSTRAINT(fk1); |
The operation fails. The foreign key is used to distribute the table. |
These examples support the information in the "Table 6-6" table:
Use ALTER TABLE to add a primary key constraint
This example creates the mytable table without a primary key or distribution clause. The table is distributed by hash on a hidden column. Then the ALTER TABLE statement is used to add a primary key constraint. The operation succeeds but the distribution key is not changed.
Command> CREATE TABLE mytable (col1 NUMBER NOT NULL, col2 VARCHAR2 (32));
Command> describe mytable;
Table SAMPLEUSER.MYTABLE:
Columns:
COL1 NUMBER NOT NULL
COL2 VARCHAR2 (32) INLINE
DISTRIBUTE BY HASH
1 table found.
(primary key columns are indicated with *)
Now alter the table to add the primary key. The operation succeeds. The distribution scheme and distribution key do not change.
Command> ALTER TABLE mytable ADD CONSTRAINT c1 PRIMARY KEY (col1);
Command> describe mytable;
Table SAMPLEUSER.MYTABLE:
Columns:
*COL1 NUMBER NOT NULL
COL2 VARCHAR2 (32) INLINE
DISTRIBUTE BY HASH
1 table found.
(primary key columns are indicated with *)Add a primary key constraint on table distributed on unique column
This example creates the mytab table and distributes the data by hash on the id2 unique column. The example then alters the mytab table adding the primary key constraint on the id column. A ttIsql describe command shows the table remains distributed by hash on the id2 column.
Command> CREATE TABLE mytab (id TT_INTEGER NOT NULL, id2 TT_INTEGER UNIQUE,
id3 TT_INTEGER) distribute by hash (id2);
Command> ALTER TABLE mytab ADD CONSTRAINT c1 PRIMARY KEY (id); Command> describe mytab;
Table SAMPLEUSER.MYTAB:
Columns:
*ID TT_INTEGER NOT NULL
ID2 TT_INTEGER UNIQUE
ID3 TT_INTEGER
DISTRIBUTE BY HASH (ID2)
1 table found.
(primary key columns are indicated with *)Use ALTER TABLE to change the distribution key
This example shows that you can use the ALTER TABLE statement to change the distribution key, but only if the table is empty.
Command> CREATE TABLE mytable2 (col1 NUMBER NOT NULL, col2 VARCHAR2 (32))
DISTRIBUTE BY HASH (col1,col2);
Command> describe mytable2;
Table SAMPLEUSER.MYTABLE2:
Columns:
COL1 NUMBER NOT NULL
COL2 VARCHAR2 (32) INLINE
DISTRIBUTE BY HASH (COL1, COL2)
1 table found.
(primary key columns are indicated with *)
Use the ALTER TABLE statement to change the distribution key to col1. The operation succeeds because the table is empty.
Command> ALTER TABLE mytable2 DISTRIBUTE BY HASH (col1);
Command> describe mytable2;
Table SAMPLEUSER.MYTABLE2:
Columns:
COL1 NUMBER NOT NULL
COL2 VARCHAR2 (32) INLINE
DISTRIBUTE BY HASH (COL1)
1 table found.
(primary key columns are indicated with *)
Insert a row of data and attempt to change the distribution key back to col1, col2. The operation fails because the table is not empty.
Command> INSERT INTO mytable2 VALUES (10, 'test'); 1 row inserted. Command> commit; Command> ALTER TABLE mytable2 DISTRIBUTE BY HASH (col1,col2); 1069: Table not empty. Alter table distribution is only permitted on empty tables. The command failed.
Add a foreign key constraint that is not part of the distribution key
This example first describes the accounts and accounts2 tables. The example then alters the accounts2 table, adding a foreign key constraint. Since this constraint is not part of the accounts2 table distribution, the operation succeeds.
Command> describe accounts;
Table SAMPLEUSER.ACCOUNTS:
Columns:
*ACCOUNT_ID NUMBER (10) NOT NULL
PHONE VARCHAR2 (15) INLINE NOT NULL
ACCOUNT_TYPE CHAR (1) NOT NULL
STATUS NUMBER (2) NOT NULL
CURRENT_BALANCE NUMBER (10,2) NOT NULL
PREV_BALANCE NUMBER (10,2) NOT NULL
DATE_CREATED DATE NOT NULL
CUST_ID NUMBER (10) NOT NULL
DISTRIBUTE BY REFERENCE (FK_CUSTOMER)
1 table found.
(primary key columns are indicated with *)
Command> describe accounts2;
Table SAMPLEUSER.ACCOUNTS2:
Columns:
*ACCOUNTS2_ID NUMBER (10) NOT NULL
ACCOUNT_ORIG_ID NUMBER (10) NOT NULL
STATUS NUMBER (2) NOT NULL
DISTRIBUTE BY HASH (ACCOUNTS2_ID)
1 table found.
(primary key columns are indicated with *)
Command> ALTER TABLE accounts2 ADD CONSTRAINT accounts2_fk FOREIGN KEY
(account_orig_id) REFERENCES accounts (account_id);
Use the ttIsql indexes command to show the accounts2_fk constraint is created successfully.
Command> indexes accounts2;
Indexes on table SAMPLEUSER.ACCOUNTS2:
ACCOUNTS2: unique range index on columns:
ACCOUNTS2_ID
ACCOUNTS2_FK: non-unique range index on columns:
ACCOUNT_ORIG_ID
(foreign key index references table SAMPLEUSER.ACCOUNTS(ACCOUNT_ID))
2 indexes found.
2 indexes found on 1 table.Attempt to drop a foreign key constraint used as a distribution key
This example attempts to drop the fk_accounts constraint. Since the constraint is used as the distribution key, the operation fails.
Command> describe transactions;
Table SAMPLEUSER.TRANSACTIONS:
Columns:
*TRANSACTION_ID NUMBER (10) NOT NULL
*ACCOUNT_ID NUMBER (10) NOT NULL
*TRANSACTION_TS TIMESTAMP (6) NOT NULL
DESCRIPTION VARCHAR2 (60) INLINE
OPTYPE CHAR (1) NOT NULL
AMOUNT NUMBER (6,2) NOT NULL
DISTRIBUTE BY REFERENCE (FK_ACCOUNTS)
1 table found.
(primary key columns are indicated with *)
Command> ALTER TABLE transactions DROP CONSTRAINT fk_accounts;
1072: Dropping a table's reference by distribution foreign key is not allowed.
The command failed.SQL syntax for ALTER TABLE: TimesTen Classic
To add one column:
ALTER TABLE [Owner.]TableName ADD [COLUMN] ColumnName ColumnDataType [DEFAULT DefaultVal] [[NOT] INLINE] [UNIQUE] [NULL] [COMPRESS (CompressColumns [,...])]
To add multiple columns:
ALTER TABLE [Owner.]TableName ADD (ColumnName ColumnDataType [DEFAULT DefaultVal] [[NOT] INLINE] [UNIQUE] [NULL] [,... ] ) [COMPRESS (CompressColumns [,...])]
To add a NOT NULL column (note that the DEFAULT clause is required):
ALTER TABLE [Owner.]TableName ADD [COLUMN] ColumnName ColumnDataType NOT NULL [ENABLE] DEFAULT DefaultVal [[NOT] INLINE] [UNIQUE] [COMPRESS (CompressColumns [,...])]
To add multiple NOT NULL columns (note that the DEFAULT clause is required):
ALTER TABLE [Owner.]TableName ADD (ColumnName ColumnDataType NOT NULL [ENABLE] DEFAULT DefaultVal [[NOT] INLINE] [UNIQUE] [,...]) [COMPRESS (CompressColumns [,...])]
The CompressColumns syntax is as follows:
{ColumnDefinition | (ColumnDefinition [,...])} BY DICTIONARY
[MAXVALUES = CompressMax]
To remove columns.
ALTER TABLE [Owner.]TableName DROP {[COLUMN] ColumnName | (ColumnName [,... ] )}
Note:
If removing columns in a compressed column group, all columns in the compressed column group must be specified.To add a primary key constraint using a range index:
ALTER TABLE [Owner.]TableName ADD CONSTRAINT ConstraintName PRIMARY KEY (ColumnName [,... ])
To add a primary key constraint using a hash index:
ALTER TABLE [Owner.]TableName ADD CONSTRAINT ConstraintName PRIMARY KEY (ColumnName [,... ]) USE HASH INDEX PAGES = RowPages | CURRENT
To add a foreign key and optionally add ON DELETE CASCADE:
ALTER TABLE [Owner.]TableName ADD [CONSTRAINT ForeignKeyName] FOREIGN KEY (ColumnName [,...]) REFERENCES RefTableName [(ColumnName [,...])] [ON DELETE CASCADE]
To remove a foreign key:
ALTER TABLE [Owner.]TableName DROP CONSTRAINT ForeignKeyName
Note:
You cannot useALTER TABLE to drop a primary key constraint. To drop the constraint, drop and recreate the table.
To resize a hash index:
ALTER TABLE [Owner.]TableName SET PAGES = RowPages | CURRENT
To change the primary key to use a hash index:
ALTER TABLE [Owner.]TableName USE HASH INDEX PAGES = RowPages | CURRENT
To change the primary key to use a range index with the USE RANGE INDEX clause:
ALTER TABLE [Owner.]TableName USE RANGE INDEX
To change the default value of a column:
ALTER TABLE [Owner.]TableName MODIFY (ColumnName DEFAULT DefaultVal)
To add or drop a unique constraint on a column:
ALTER TABLE Owner.]TableName {ADD | DROP} UNIQUE (ColumnName)
To remove the default value of a column that is nullable, by changing it to NULL:
ALTER TABLE [Owner.]TableName MODIFY (ColumnName DEFAULT NULL)
To add LRU aging:
ALTER TABLE [Owner.]TableName ADD AGING LRU [ON | OFF]
To add time-based aging:
ALTER TABLE [Owner.]TableName ADD AGING USE ColumnName LIFETIME num1 {SECOND[S] | MINUTE[S] | HOUR[S] | DAY[S]} [CYCLE num2 {SECOND[S] | MINUTE[S] | HOUR[S] | DAY[S] }] [ON | OFF]
To change the aging state:
ALTER TABLE [Owner.]TableName SET AGING {ON | OFF}
To drop aging:
ALTER TABLE [Owner.]TableName DROP AGING
To change the lifetime for time-based aging:
ALTER TABLE [Owner.]TableName SET AGING LIFETIME num1 {SECOND[S] | MINUTE[S] | HOUR[S] | DAY[S]}
To change the cycle for time-based aging:
ALTER TABLE [Owner.]TableName SET AGING CYCLE num2 {SECOND[S] | MINUTE[S] | HOUR[S] | DAY[S]}
Parameters for ALTER TABLE: TimesTen Classic
| Parameter | Description |
|---|---|
|
|
Identifies the table to be altered. |
|
|
Specifies that in the column |
|
|
Specifies that an attribute of a given column is to be changed to a new value. |
|
|
Specifies that the column has a default value, Altering the default value of a column has no impact on existing rows. Note: To add a |
|
|
Name of the column participating in the |
|
|
Type of the column to be added. Some types require additional parameters. See "Data Types" for the data types that can be specified. |
|
|
If you add a column, you can specify |
|
|
By default, variable-length columns whose declared column length is > 128 bytes are stored out of line. Variable-length columns whose declared column length is <= 128 bytes are stored inline. The default behavior can be overridden during table creation through the use of the |
|
|
Defines a compressed column group for a table that is enabled for compression. This can include one or more columns in the table. If you define multiple columns for a compression group, you must specify the columns as Each compressed column group is limited to a maximum of 16 columns. See "Column-based compression of tables (TimesTen Classic)" for details on compression columns. |
|
|
Defines a compression dictionary for each compressed column group. |
|
|
For the dictionary table,
The maximum size defaults to size of 232-1 if the See "Column-based compression of tables (TimesTen Classic)" for details on maximum sizing for compression dictionaries. |
|
|
Adds a primary key constraint to the table. Columns of the primary key must be defined as Specify Specify the If you specify The value for TimesTen recommends that you do not specify If your estimate is too small, performance may be degraded. See "Column definition: TimesTen Classic" for more information on hash indexes. Note: Before you use |
|
|
Specifies that a foreign key is to be dropped. Optionally specifies that an added foreign key is named by the user. |
|
|
Name of the foreign key to be added or dropped. All foreign keys are assigned a default name by the system if the name was not specified by the user. Either the user-provided name or system name can be specified in the |
|
|
Specifies that a foreign key is to be added. |
|
|
Specifies that the foreign key references another table. |
|
|
The name of the table that the foreign key references. |
|
|
Enables the |
|
|
Changes primary key to use a hash index. If the primary key already uses a hash index, then this clause is equivalent to the |
|
|
Changes primary key to use a range index. If the primary key already uses a range index, TimesTen ignores this clause. |
|
|
Resizes the hash index to reflect the expected number of pages in the table. If you specify The value for TimesTen recommends that you do not specify If your estimate is too small, performance may be degraded. See "Column definition: TimesTen Classic" for more information on hash indexes. |
|
|
Adds least recently used (LRU) aging to an existing table that has no aging policy defined. The LRU aging policy defines the type of aging (least recently used (LRU)), the aging state ( Set the aging state to either LRU attributes are defined by calling the |
|
|
Adds time-based aging to an existing table that has no aging policy defined. The time-based aging policy defines the type of aging (time-based), the aging state ( Set the aging state to either Time-based aging attributes are defined at the SQL level and are specified by the Specify The values of the column used for aging are updated by your applications. If the value of this column is unknown for some rows, and you do not want the rows to be aged, define the column with a large default value (the column cannot be You can define your aging column with a data type of For more information about time-based aging, see "Implementing an aging policy in your tables" in Oracle TimesTen In-Memory Database Operations Guide. |
|
|
Specify the The Specify The concept of time resolution is supported. If |
|
|
Specify the optional
The Specify If you do not specify the If the aging state is Specify the |
|
|
Changes the aging state. The aging policy must be previously defined. |
|
|
Drops the aging policy from the table. After you define an aging policy, you cannot alter it. Drop aging, then redefine. |
|
|
Use this clause to change the lifetime for time-based aging.
If you defined your aging column with data type |
|
|
Use this clause to change the cycle for time-based aging.
|
Description for ALTER TABLE: TimesTen Classic
-
The
ALTER TABLEstatement cannot be used to alter a temporary table. -
The
ALTER TABLE ADD [COLUMN]ColumnNamestatement adds one or more new columns to an existing table. When you add one or more columns, the new columns are added to the end of all existing rows of the table in one new partition. -
The
ALTER TABLEADDorDROP COLUMNstatement can be used to add or drop columns from replicated tables.Do not use
ALTERTABLEto alter a replicated table that is part of aTWOSAFE BY REQUESTtransaction. -
Columns referenced by materialized views cannot be dropped.
-
You cannot use the
ALTERTABLEstatement to add a column, drop a column, or add a constraint for cache group tables. -
Only one partition is added to the table per statement regardless of the number of columns added.
-
You can
ALTERa table to add aNOTNULLcolumn with a default value. TheDEFAULTclause is required. Restrictions include:-
You cannot use the column as a primary key column. Specifically, you cannot specify the column in the statement:
ALTERTABLEADDConstraintNamePRIMARYKEY(ColumnName[,...]). -
You cannot use the column for time-based aging. Specifically, you cannot specify the column in the statement
ALTER TABLE ADD AGING USEColumnName.Note:
To add aNOT NULLcolumn to a table that is part of a replication scheme,DDL_REPLICATON_LEVELmust be 3 or greater.
-
-
NULLis the initial value for all added columns, unless a default value is specified for the new column. -
The total number of columns in the table cannot exceed 1000. In addition, the total number of partitions in a table cannot exceed 1000, one of which is used by TimesTen.
-
Use the
ADD CONSTRAINT ... PRIMARY KEYclause to add a primary key constraint to a regular table or to a detailed or materialized view table. Do not use this clause on a table that already has a primary key. -
If you use the
ADD CONSTRAINT... PRIMARY KEYclause to add a primary key constraint, and you do not specify theUSE HASH INDEXclause, then a range index is used for the primary key constraint. -
If a table is replicated and the replication agent is active, you cannot use the
ADD CONSTRAINT ... PRIMARY KEYclause. Stop the replication agent first. -
Do not specify the
ADD CONSTRAINT ... PRIMARY KEYclause on a global temporary table. -
Do not specify the
ADD CONSTRAINT ... PRIMARY KEYclause on a cache group table because cache group tables defined with a primary key must be defined in theCREATE CACHE GROUPstatement. -
As the result of an
ALTER TABLE ADDstatement, an additional read occurs for each new partition during queries. Therefore, altered tables may have slightly degraded performance. The performance can only by restored by dropping and recreating the table, or by using thettMigrate create -c-relaxedUpgradecommand, and restoring the table using thettRestore -r-relaxedUpgradecommand. Dropping the added column does not recover the lost performance or decrease the number of partitions. -
When you use the
ALTER TABLE DROPstatement to remove one or more columns from an existing table, dropped columns are removed from all current rows of the table. Subsequent SQL statements must not attempt to make any use of the dropped columns. You cannot drop columns that are in the table's primary key. You cannot drop columns that are in any of the table's foreign keys until you have dropped all foreign keys. You cannot drop columns that are indexed until all indexes on the column have been dropped.ALTER TABLEcannot be used to drop all of the columns of a table. UseDROP TABLEinstead. -
When a column is dropped from a table, all commands referencing that table need to be recompiled. An error may result at recompilation time if a dropped column was referenced. The application must re-prepare those commands, and rebuild any parameters and result columns. When a column is added to a table, the commands that contain a
SELECT *statement are invalidated. Only these commands must be re-prepared. All other commands continue to work as expected. -
When you drop a column, the column space is not freed.
-
When you add a
UNIQUEconstraint, there is overhead incurred (in terms of additional space and additional time). This is because an index is created to maintain theUNIQUEconstraint. You cannot use theDROP INDEXstatement to drop an index used to maintain theUNIQUEconstraint. -
A
UNIQUEconstraint and its associated index cannot be dropped if it is being used as a unique index on a replicated table. -
Use
ALTER TABLE...USE RANGE INDEXif your application performs range queries over a table's primary key. -
Use
ALTER TABLE...USE HASH INDEXif your application performs exact match lookups on a table's primary key. -
An error is generated if a table has no primary key and either the
USE HASH INDEXclause or theUSE RANGE INDEXclause is specified. -
Make sure to stop the replication agent before adding or dropping a foreign key on a replicated table.
-
If
ON DELETE CASCADEis specified on a foreign key constraint for a child table, a user can delete rows from a parent table for which the user has theDELETEprivilege without requiring explicitDELETEprivilege on the child table. -
To change the
ON DELETE CASCADEtriggered action, drop then redefine the foreign key constraint. -
ON DELETE CASCADEis supported on detail tables of a materialized view. If you have a materialized view defined over a child table, a deletion from the parent table causes cascaded deletes in the child table. This, in turn, triggers changes in the materialized view. -
The total number of rows reported by the
DELETEstatement does not include rows deleted from child tables as a result of theON DELETE CASCADEaction. -
For
ON DELETE CASCADE, since different paths may lead from a parent table to a child table, the following rule is enforced: -
Either all paths from a parent table to a child table are "delete" paths or all paths from a parent table to a child table are "do not delete" paths.
-
Specify
ON DELETE CASCADEon all child tables on the "delete" path. -
This rule does not apply to paths from one parent to different children or from different parents to the same child.
-
-
For
ON DELETE CASCADE, a second rule is also enforced: -
If a table is reached by a "delete" path, then all its children are also reached by a "delete" path.
-
For
ON DELETE CASCADEwith replication, the following restrictions apply:-
The foreign keys specified with
ON DELETE CASCADEmust match between the Master and subscriber for replicated tables. Checking is done at runtime. If there is an error, the receiver thread stops working. -
All tables in the delete cascade tree have to be replicated if any table in the tree is replicated. This restriction is checked when the replication scheme is created or when a foreign key with
ON DELETE CASCADEis added to one of the replication tables. If an error is found, the operation is aborted. You may be required to drop the replication scheme first before trying to change the foreign key constraint.
-
-
The
ALTER TABLE ADD/DROP CONSTRAINTstatement has the following restrictions:-
When a foreign key is dropped, TimesTen also drops the index associated with the foreign key. Attempting to drop an index associated with a foreign key using the regular
DROP INDEXstatement results in an error. -
Foreign keys cannot be added or dropped on tables in a cache group.
-
Foreign keys cannot be added or dropped on views or temporary tables.
-
You cannot use
ALTER TABLEto drop a primary key constraint. You would have to drop and recreate the table in order to drop the constraint.
-
-
After you have defined an aging policy for the table, you cannot change the policy from LRU to time-based or from time-based to LRU. You must first drop aging and then alter the table to add a new aging policy.
-
The aging policy must be defined to change the aging state.
-
The following rules determine if a row is accessed or referenced for LRU aging:
-
Any rows used to build the result set of a
SELECTstatement. -
Any rows used to build the result set of an
INSERT ... SELECTstatement. -
Any rows that are about to be updated or deleted.
-
-
Compiled commands are marked invalid and need recompilation when you either drop LRU aging from or add LRU aging to tables that are referenced in the commands.
-
Call the
ttAgingScheduleNowprocedure to schedule the aging process right away regardless if the aging state isONorOFF. -
For the time-based aging policy, you cannot add or modify the aging column. This is because you cannot add or modify a
NOT NULLcolumn. -
Aging restrictions:
-
You cannot drop the column that is used for time-based aging.
-
Tables that are related by foreign keys must have the same aging policy.
-
For LRU aging, if a child row is not a candidate for aging, neither this child row nor its parent row are deleted.
ON DELETE CASCADEsettings are ignored. -
For time-based aging, if a parent row is a candidate for aging, then all child rows are deleted.
ON DELETE CASCADE(whether specified or not) is ignored.
-
-
Restrictions for column-based compression of tables:
-
You can add compressed column groups with the
ALTER TABLEstatement only if the table was enabled for compression at table creation. You can add uncompressed columns to any table, including tables enabled for compression. Refer to "Column-based compression of tables (TimesTen Classic)" for more details on adding compressed column groups to a table. -
You cannot modify columns of a compressed column group.
-
You can drop all columns within a compressed column group with the
ALTER TABLEcommand; when removing columns in a compressed column group, all columns in the compressed column group must be specified for removal. -
You cannot use
ALTER TABLEto modify an existing uncompressed column to make it compressed. For example:Command> create table mytab (a varchar2 (30), b int, c int) compress ((a,b) by dictionary); Command> alter table mytab add (d int) compress (c by dictionary); 2246: Cannot change compression clause for already defined column C The command failed.
-
Understanding partitions when using ALTER TABLE in TimesTen
When you create a table, an initial partition is created. If you ALTER the table, and add additional columns, secondary partitions are created. There is one secondary partition created for each ALTER TABLE statement. For a column in secondary partitions, you cannot create a primary key constraint on the column or use the column for time-based aging.
You can use ttMigrate -r -relaxedUpgrade to condense multiple partitions. This means the initial partition plus one or more secondary partitions are condensed into a single partition called the initial partition. Once you condense the partitions, you can then ALTER the table and add a primary key constraint on the column or use the column for time-based aging. This is because the columns are no longer in secondary partitions but are now in the initial partition.
If your database is involved in replication and you want to condense multiple partitions, you must use the StoreAttribute TABLE DEFINITION CHECKING RELAXED (of the CREATE REPLICATION statement). Run ttMigrate -r -relaxedUpgrade on both the master and subscriber or on either the master or subscriber by using -duplicate.
Use ttSchema to view partition numbers for columns. ttSchema displays secondary partition number 1 as partition 1, secondary partition number 2 as partition 2 and so on.
As an example, create a table MyTab with 2 columns. Then ALTER the table adding 2 columns (Col3 and Col4) with the NOT NULL DEFAULT clause.
Command> CREATE TABLE MyTab (Col1 NUMBER, Col2 VARCHAR2 (30));
Command> ALTER TABLE MyTab ADD (Col3 NUMBER NOT NULL DEFAULT 10, Col4 TIMESTAMP
NOT NULL DEFAULT TIMESTAMP '2012-09-03 12:00:00');
Use ttSchema to verify Col3 and Col4 are in secondary partition 1.
ttschema -DSN sampledb_1122
-- Database is in Oracle type mode
create table TESTUSER.MYTAB (
COL1 NUMBER,
COL2 VARCHAR2(30 BYTE) INLINE,
COL3 NUMBER NOT NULL DEFAULT 10,
COL4 TIMESTAMP(6) NOT NULL DEFAULT TIMESTAMP '2012-09-03 12:00:00');
-- column COL3 partition 1
-- column COL4 partition 1
Attempt to add a primary key constraint on Col3 and time-based aging on Col4. You see errors because you can neither add a primary key constraint nor add time-based aging to a column that is not in the initial partition.
Command> ALTER TABLE MyTab ADD CONSTRAINT PriKey PRIMARY KEY (Col3); 2419: All columns in a primary key constraint must be in the initial partition; column COL3 was added by ALTER TABLE The command failed. Command> ALTER TABLE MyTab ADD AGING USE Col4 LIFETIME 3 DAYS; 3023: Aging column must be in the initial partition; column COL4 was added by ALTER TABLE The command failed.
Use ttMigrate with the -relaxedUpgrade option to condense the partitions. Then use ttSchema to verify the partitions are condensed and there are no columns in secondary partition 1.
ttMigrate -c dsn=sampledb_1122 test.migrate
Saving user PUBLIC
User successfully saved.
Saving table TESTUSER.MYTAB
Saving rows...
0/0 rows saved.
Table successfully saved.
ttDestroy sampledb_1122
ttMigrate -r -relaxedUpgrade
dsn=sampledb_1122 test.migrate
Restoring table TESTUSER.MYTAB
Restoring rows...
0/0 rows restored.
Table successfully restored.
ttSchema DSN=sampledb_1122
-- Database is in Oracle type mode
create table TESTUSER.MYTAB (
COL1 NUMBER,
COL2 VARCHAR2(30 BYTE) INLINE,
COL3 NUMBER NOT NULL DEFAULT 10,
COL4 TIMESTAMP(6) NOT NULL DEFAULT TIMESTAMP '2012-09-03 12:00:00');
Now add a primary key constraint on Col3 and time-based aging on Col4. The results are successful because Col3 and Col4 are in the initial partition as a result of ttMigrate. Use ttSchema to verify results.
Command> ALTER TABLE MyTab ADD CONSTRAINT PriKey PRIMARY KEY (Col3);
Command> ALTER TABLE MyTab ADD AGING USE Col4 LIFETIME 3 DAYS;
ttschema sampledb_1122
-- Database is in Oracle type mode
create table TESTUSER.MYTAB (
COL1 NUMBER,
COL2 VARCHAR2(30 BYTE) INLINE,
COL3 NUMBER NOT NULL DEFAULT 10,
COL4 TIMESTAMP(6) NOT NULL DEFAULT TIMESTAMP '2012-09-03 12:00:00')
AGING USE COL4 LIFETIME 3 days CYCLE 5 minutes ON;
alter table TESTUSER.MYTAB add constraint PRIKEY primary key (COL3);Examples for ALTER TABLE: TimesTen Classic
Add returnrate column to parts table.
ALTER TABLE parts ADD COLUMN returnrate DOUBLE;
Add numsssign and prevdept columns to contractor table.
ALTER TABLE contractor ADD ( numassign INTEGER, prevdept CHAR(30) );
Remove addr1 and addr2 columns from employee table.
ALTER TABLE employee DROP ( addr1, addr2 );
Drop the UNIQUE title column of the books table.
ALTER TABLE books DROP UNIQUE (title);
Add the x1 column to the t1 table with a default value of 5:
ALTER TABLE t1 ADD (x1 INT DEFAULT 5);
Change the default value of column x1 to 2:
ALTER TABLE t1 MODIFY (x1 DEFAULT 2);
Alter table primarykeytest to add the primary key constraint c1. Use the ttIsql INDEXES command to show that the primary key constraint c1 is created and a range index is used:
Command> CREATE TABLE primarykeytest (col1 TT_INTEGER NOT NULL);
Command> ALTER TABLE primarykeytest ADD CONSTRAINT c1
PRIMARY KEY (col1);
Command> INDEXES primarykeytest;
Indexes on table SAMPLEUSER.PRIMARYKEYTEST:
C1: unique range index on columns:
COL1
1 index found.
1 index found on 1 table.
Alter table prikeyhash to add the primary key constraint c2 using a hash index. Use the ttIsql INDEXES command to show that the primary key constraint c2 is created and a hash index is used:
Command> CREATE TABLE prikeyhash (col1 NUMBER (3,2) NOT NULL);
Command> ALTER TABLE prikeyhash ADD CONSTRAINT c2
PRIMARY KEY (col1) USE HASH INDEX PAGES = 20;
Command> INDEXES prikeyhash;
Indexes on table SAMPLEUSER.PRIKEYHASH:
C2: unique hash index on columns:
COL1
1 index found.
1 table found.
Attempt to add a primary key constraint on a table already defined with a primary key. You see an error:
Command> CREATE TABLE oneprikey (col1 VARCHAR2 (30) NOT NULL, col2 TT_BIGINT NOT NULL, col3 CHAR (15) NOT NULL, PRIMARY KEY (col1,col2)); Command> ALTER TABLE oneprikey ADD CONSTRAINT c2 PRIMARY KEY (col1,col2); 2235: Table can have only one primary key The command failed.
Attempt to add a primary key constraint on a column that is not defined as NOT NULL. You see an error:
Command> CREATE TABLE prikeynull (col1 CHAR (30)); Command> ALTER TABLE prikeynull ADD CONSTRAINT c3 PRIMARY KEY (col1); 2236: Nullable column cannot be part of a primary key The command failed.
This example illustrates the use of range and hash indexes. It creates the pkey table with col1 as the primary key. A range index is created by default. The table is then altered to change the index on col1 to a hash index. The table is altered again to change the index back to a range index.
Command> CREATE TABLE pkey (col1 TT_INTEGER PRIMARY KEY, col2 VARCHAR2 (20)); Command> INDEXES pkey; Indexes on table SAMPLEUSER.PKEY: PKEY: unique range index on columns: COL1 1 index found. 1 index found on 1 table.
Alter the pkey table to use a hash index:
Command> ALTER TABLE pkey USE HASH INDEX PAGES = CURRENT; Command> INDEXES pkey; Indexes on table SAMPLEUSER.PKEY: PKEY: unique hash index on columns: COL1 1 index found. 1 table found.
Alter the pkey table to use a range index with the USE RANGE INDEX clause:
Command> ALTER TABLE pkey USE RANGE INDEX; Command> INDEXES pkey; Indexes on table SAMPLEUSER.PKEY: PKEY: unique range index on columns: COL1 1 index found. 1 table found.
This example generates an error when attempting to alter a table to define either a range or hash index on a column without a primary key.
Command> CREATE TABLE myindex (Ccl1 CHAR (20)); Command> ALTER TABLE myindex USE RANGE INDEX; 2810: The table has no primary key so cannot change its index type The command failed. Command> ALTER TABLE myindex USE HASH INDEX PAGES = CURRENT; 2810: The table has no primary key so cannot change its index type The command failed.
These examples show how time resolution works with aging. In this example, lifetime is three days.
-
If
(SYSDATE - ColumnValue) <= 3, do not age out the row. -
If
(SYSDATE - ColumnValue) > 3, then the row is a candidate for aging. -
If
(SYSDATE - ColumnValue) = 3 days, 22 hours, then row is not aged out because lifetime was specified in days. The row would be aged out if lifetime had been specified as 72 hours.
This example alters a table by adding LRU aging. The table has no previous aging policy. The aging state is ON by default.
ALTER TABLE agingdemo3 ADD AGING LRU; Command> DESCRIBE agingdemo3; Table USER.AGINGDEMO3: Columns: *AGINGID NUMBER NOT NULL NAME VARCHAR2 (20) INLINE Aging lru on 1 table found. (primary key columns are indicated with *)
This example alters a table by adding time-based aging. The table has no previous aging policy. The agingcolumn column is used for aging. LIFETIME is 2 days. CYCLE is 30 minutes.
ALTER TABLE agingdemo4 ADD AGING USE agingcolumn LIFETIME 2 DAYS CYCLE 30 MINUTES; Command> DESCRIBE agingdemo4; Table USER.AGINGDEMO4: Columns: *AGINGID NUMBER NOT NULL NAME VARCHAR2 (20) INLINE AGINGCOLUMN TIMESTAMP (6) NOT NULL Aging use AGINGCOLUMN lifetime 2 days cycle 30 minutes on
This example illustrates that after you create an aging policy, you cannot change it. You must drop aging and redefine.
CREATE TABLE agingdemo5 (agingid NUMBER NOT NULL PRIMARY KEY ,name VARCHAR2 (20) ,agingcolumn TIMESTAMP NOT NULL ) AGING USE agingcolumn LIFETIME 3 DAYS OFF; ALTER TABLE agingdemo5 ADD AGING LRU; 2980: Cannot add aging policy to a table with an existing aging policy. Have to drop the old aging first The command failed.
Drop aging on the table and redefine with LRU aging.
ALTER TABLE agingdemo5 DROP AGING; ALTER TABLE agingdemo5 ADD AGING LRU; Command> DESCRIBE agingdemo5; Table USER.AGINGDEMO5: Columns: *AGINGID NUMBER NOT NULL NAME VARCHAR2 (20) INLINE AGINGCOLUMN TIMESTAMP (6) NOT NULL Aging lru on 1 table found. (primary key columns are indicated with *)
This example alters a table by setting the aging state to OFF. The table has been defined with a time-based aging policy. If you set the aging state to OFF, aging is not done automatically. This is useful to use an external scheduler to control the aging process. Set aging state to OFF and then call the ttAgingScheduleNow procedure to start the aging process.
Command> DESCRIBE agingdemo4; Table USER.AGINGDEMO4: Columns: *AGINGID NUMBER NOT NULL NAME VARCHAR2 (20) INLINE AGINGCOLUMN TIMESTAMP (6) NOT NULL Aging use AGINGCOLUMN lifetime 2 days cycle 30 minutes on ALTER TABLE AgingDemo4 SET AGING OFF;
Note that when you describe agingdemo4, the aging policy is defined and the aging state is set to OFF.
Command> DESCRIBE agingdemo4; Table USER.AGINGDEMO4: Columns: *AGINGID NUMBER NOT NULL NAME VARCHAR2 (20) INLINE AGINGCOLUMN TIMESTAMP (6) NOT NULL Aging use AGINGCOLUMN lifetime 2 days cycle 30 minutes off 1 table found. (primary key columns are indicated with *)
Call ttAgingScheduleNow to invoke aging with an external scheduler:
Command> CALL ttAgingScheduleNow ('agingdemo4');
Attempt to alter a table adding the aging column and then use that column for time-based aging. An error is generated.
Command> DESCRIBE x; Table USER1.X: Columns: *ID TT_INTEGER NOT NULL 1 table found. (primary key columns are indicated with *) Command> ALTER TABLE x ADD COLUMN t TIMESTAMP; Command> ALTER TABLE x ADD AGING USE t LIFETIME 2 DAYS; 2993: Aging column cannot be nullable The command failed.
Attempt to alter the LIFETIME clause for a table defined with time-based aging. The aging column is defined with data type TT_DATE. An error is generated because the LIFETIME unit is not expressed in DAYS.
Command> CREATE TABLE aging1 (col1 TT_DATE NOT NULL) AGING USE col1 LIFETIME 2 DAYS; Command> ALTER TABLE aging1 SET AGING LIFETIME 2 HOURS; 2977: Only DAY lifetime unit is allowed with a TT_DATE column The command failed.
Alter the employees table to add a new compressed column of state, which contains the full name of the state. Note that the employees table already has a compressed column group consisting of job_id and manager_id.
Command> ALTER TABLE employees
ADD COLUMN state VARCHAR2(20)
COMPRESS (state BY DICTIONARY);
Command> DESCRIBE employees;
Table MYSCHEMA.EMPLOYEES:
Columns:
*EMPLOYEE_ID NUMBER (6) NOT NULL
FIRST_NAME VARCHAR2 (20) INLINE
LAST_NAME VARCHAR2 (25) INLINE NOT NULL
EMAIL VARCHAR2 (25) INLINE NOT NULL
PHONE_NUMBER VARCHAR2 (20) INLINE
HIRE_DATE DATE NOT NULL
JOB_ID VARCHAR2 (10) INLINE NOT NULL
SALARY NUMBER (8,2)
COMMISSION_PCT NUMBER (2,2)
MANAGER_ID NUMBER (6)
DEPARTMENT_ID NUMBER (4)
STATE VARCHAR2 (20) INLINE
COMPRESS ( ( JOB_ID, MANAGER_ID ) BY DICTIONARY,
STATE BY DICTIONARY )
1 table found.
(primary key columns are indicated with *)
The following example drops the compressed column state from the employees table:
Command> ALTER TABLE employees
DROP state;
Command> DESCRIBE employees;
Table MYSCHEMA.EMPLOYEES:
Columns:
*EMPLOYEE_ID NUMBER (6) NOT NULL
FIRST_NAME VARCHAR2 (20) INLINE
LAST_NAME VARCHAR2 (25) INLINE NOT NULL
EMAIL VARCHAR2 (25) INLINE NOT NULL
PHONE_NUMBER VARCHAR2 (20) INLINE
HIRE_DATE DATE NOT NULL
JOB_ID VARCHAR2 (10) INLINE NOT NULL
SALARY NUMBER (8,2)
COMMISSION_PCT NUMBER (2,2)
MANAGER_ID NUMBER (6)
DEPARTMENT_ID NUMBER (4)
COMPRESS ( ( JOB_ID, MANAGER_ID ) BY DICTIONARY )
1 table found.
(primary key columns are indicated with *)See also
ALTER USER
The ALTER USER statement enables you to change a user's password. It also enables you to change the profile for the user, to lock or unlock the user's account, and to expire the user's password. A user with the ADMIN privilege can perform these operations.
This statement also enables you to change a user from internal to external or from external to internal.
Required privilege
No privilege is required to change the user's own password.
ADMIN privilege is required for all other operations.
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
This is the syntax for ALTER USER...IDENTIFIED BY. Ensure to specify at least one of these clauses: IDENTIFIED BY, PROFILE, ACCOUNT, or PASSWORD EXPIRE.
ALTER USER user [IDENTIFIED BY {password | "password"}]
[PROFILE profile] [ACCOUNT {LOCK|UNLOCK}] [PASSWORD EXPIRE]
This is the syntax for ALTER USER...IDENTIFIED EXTERNALLY. Ensure to specify at least one of these clauses: IDENTIFIED EXTERNALLY, PROFILE, or ACCOUNT.
ALTER USER user [IDENTIFIED EXTERNALLY] [PROFILE profile] [ACCOUNT {LOCK|UNLOCK}]
Parameters
| Parameter | Description |
|---|---|
|
|
Name of the user to alter. |
|
|
Specifies an internal user and the password for the internal user. The password you can specify is dependent on the profile assigned to the user. Specifically, the value of the |
|
|
Specifies the user is an external user. |
|
|
Use the |
|
|
Specify |
|
|
Specify |
Description
-
Database users can be internal or external.
-
Internal users are defined for a TimesTen database.
-
External users are defined by the operating system. External users cannot be assigned a TimesTen password.
-
- Password requirements:
- Cannot exceed 30 characters.
- Is case-sensitive.
- Must start with a letter. A password cannot start with a digit or a special character unless the password is enclosed in double quotation marks.
- If a special character is used, the password must be contained in double quotation marks. The exceptions are the
#and the@special characters. A password that contains the#or the@special character does not need to be enclosed in double quotation marks. - Cannot contain a semi-colon (
;) or a double quotation mark (").
-
Use the
PROFILEclause to change the profile for a user. See "CREATE PROFILE" for details. -
Use the
ACCOUNTLOCKorACCOUNTUNLOCKto change the lock settings for the user account. -
Use the
PASSWORDEXPIREclause to expire the user's password and force a password change before the user can connect to the database. -
You can alter a user over a client/sever connection if the connection is encrypted with TLS. See "Transport Layer Security for TimesTen Client/Server" in the Oracle TimesTen In-Memory Database Security Guide for details.
-
When replication is configured, this statement is replicated.
Examples
Illustrate password verification when altering user
This example creates the myprofile_strongpw profile and specifies a value of TT_STRONG_VERIFY_FUNCTION for the PASSWORD_COMPLEXITY_CHECKER password parameter. The example then creates the sampleuser_pwchange user and assigns the myprofile_strongpw profile to this user. The specified password meets the requirements of the TT_STRONG_VERIFY_FUNCTION function and the user is created. See "TT_STRONG_VERIFY_FUNCTION" for more information on the TT_STRONG_VERIFY_FUNCTION function.
Command> CREATE PROFILE myprofile_strongpw LIMIT
PASSWORD_COMPLEXITY_CHECKER TT_STRONG_VERIFY_FUNCTION;
Profile created.
Command> CREATE USER sampleuser_pwchange
IDENTIFIED BY "5&AbbN*60" PROFILE myprofile_strongpw;
User created.Now alter the myprofile_strongpw profile, changing the value of the PASSWORD_COMPLEXITY_CHECKER password parameter to TT_STIG_VERIFY_FUNCTION. Use the ALTER USER statement to expire the password for the sampleuser_pwchange user. Attempt to connect to the database as the sampleuser_pwchange user. The connection fails, as the password is expired.
Command> ALTER PROFILE myprofile_strongpw LIMIT
PASSWORD_COMPLEXITY_CHECKER TT_STIG_VERIFY_FUNCTION;
Profile altered.
Command> ALTER USER sampleuser_pwchange PASSWORD EXPIRE;
User altered.
Command> GRANT CONNECT TO sampleuser_pwchange;
Command> connect adding "UID=sampleuser_pwchange;PWD=5&AbbN*60" as sampleuser;
15180: the password has expired
The command failed.
Use the ALTER USER statement to change the password for the sampleuser_pwchange user. The ALTER USER statement succeeds, as the password meets the requirements of the TT_STIG_VERIFY_FUNCTION function. Attempt to connect to the database as the sampleuser_pwchange user. The connection is successful. See "TT_STIG_VERIFY_FUNCTION" for more information on the TT_STIG_VERIFY_FUNCTION function.
access1: Command> ALTER USER sampleuser_pwchange
IDENTIFIED BY "bd@<!BCvvKASn67";
User altered.
Command> connect adding "UID=sampleuser_pwchange;PWD=bd@<!BCvvKASn67"
as sampleuser;
Connection successful: DSN=access1;UID=sampleuser_pwchange;
DataStore=/scratch/sampleuser/mydatabase1;DatabaseCharacterSet=AL32UTF8;
ConnectionCharacterSet=AL32UTF8;PermSize=128;
(Default setting AutoCommit=1)
Change the user's profile
This example creates the user1 user and assigns the user1 user the profile1 profile. The example then uses the ALTER USER statement to change the user1 user's profile to profile2.
Command> CREATE USER user1 IDENTIFIED BY user1 PROFILE profile1; User created. Command> ALTER USER user1 PROFILE profile2; User altered.
Query the dba_users system view to verify the user1 profile has been changed to profile2.
Command> SELECT profile FROM dba_users WHERE username = 'USER1'; < PROFILE2 > 1 row found.
Lock and unlock a user's account
This example creates the user2 user. It then uses the ALTER USER statement to lock and then unlock the user2 user's account.
Command> CREATE USER user2 IDENTIFIED BY user2 PROFILE profile1; User created. Command> ALTER USER user2 ACCOUNT LOCK; User altered.
Grant the CONNECT privilege to user2;
Command> GRANT CONNECT TO user2;
Attempt to connect to the database as user2. The user2 account is locked so the connection fails.
Command> connect adding "UID=user2;PWD=user2" as user2; 15179: the account is locked The command failed.
As the instance administrator, reconnect to the database and use the ALTER USER statement to unlock the user2 account.
none: Command> use database1 database1: Command> ALTER USER user2 ACCOUNT UNLOCK; User altered.
Attempt to connect to the database as the user2 user. The connection succeeds.
database1: Command> connect adding "UID=user2;PWD=user2" as user2; Connection successful: DSN=database1;UID=user3;DataStore=/scratch/database1; DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=AL32UTF8;PermSize=128; (Default setting AutoCommit=1)
Expire a user's password
This example uses the ALTER USER statement to change the user2 user's account to expire the password. A user with ADMIN privilege must change the user2 password before user2 can connect to the database.
Command> ALTER USER user2 PASSWORD EXPIRE; User altered.
Attempt to connect to the database as user2. The user2 password must be changed before the user2 user can connect to the database.
Command> connect adding "UID=user2;PWD=user2" as user2; 15180: the password has expired The command failed.
As the instance administrator, reconnect to the database and use the ALTER USER statement to change the user2 password.
none: Command> use database1 database1: Command> ALTER USER user2 IDENTIFIED BY newuser2password; User altered.
Attempt to connect to the database a the user2 user. The connection succeeds.
database1: Command> connect adding "UID=user2;PWD=newuser2password" as user2; Connection successful: DSN=database1;UID=user4;DataStore=/scratch/database1; DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=AL32UTF8;PermSize=128; (Default setting AutoCommit=1)
Change a user from external to internal and internal to external
This example uses the ALTER USER statement to change the user2 internal user to an external user and then back to an internal user.
Command> ALTER USER user2 IDENTIFIED EXTERNALLY; User altered.
Use the ALTER USER statement to change the user2 external user back to an internal user.
Command> ALTER USER user2 IDENTIFIED BY user2_password_change; User altered.
See also
CALL
Use the CALL statement to execute a TimesTen built-in procedure or to execute a PL/SQL procedure or function that is standalone or part of a package from within SQL.
Required privilege
The privileges required for executing each TimesTen built-in procedure are listed in the description of each procedure in the "Built-In Procedures" section in the Oracle TimesTen In-Memory Database Reference.
No privileges are required for an owner calling its own PL/SQL procedure or function that is standalone or part of a package using the CALL statement. For all other users, the EXECUTE privilege on the procedure or function or on the package in which it is defined is required.
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
To call a TimesTen built-in procedure:
CALL TimesTenBuiltIn [( arguments )]
When calling PL/SQL procedures or functions that are standalone or part of a package, you can either call these by name or as the result of an expression.
To call a PL/SQL procedure:
CALL [Owner.][Package.]ProcedureName [( arguments )]
To call a PL/SQL function that returns a parameter, one of the following are appropriate:
CALL [Owner.][Package.]FunctionName [(arguments)] INTO :return_param
Note:
A user's own PL/SQL procedure or function takes precedence over a TimesTen built-in procedure with the same name.
Parameters
| Parameter | Description |
|---|---|
|
|
Name of the TimesTen built-in procedure. For a full list of TimesTen built-in procedures, see "Built-In Procedures" in the Oracle TimesTen In-Memory Database Reference. |
|
|
Name of the PL/SQL procedure. You can optionally specify the owner of the procedure. |
|
|
Name of the PL/SQL function. You can optionally specify the owner of the function. |
|
|
Specify 0 or more arguments for the PL/SQL procedure or function. |
|
|
If the routine is a function, the |
|
|
Specify the host variable that stores the return value of the function. |
Description
Detailed information on how to execute PL/SQL procedures or functions with the CALL statement in TimesTen is provided in "Executing procedures and functions" in the Oracle TimesTen In-Memory Database PL/SQL Developer's
Guide, "Using CALL to execute procedures and functions" in the Oracle TimesTen In-Memory Database C Developer's Guide, or "Using CALL to execute procedures and functions" in the Oracle TimesTen In-Memory Database Java Developer's Guide.
Examples
The following is the definition of the mytest function:
create or replace function mytest return number is begin return 1; end; /
Perform the following to execute the mytest function in a CALL statement:
Command> variable n number; Command> call mytest() into :n; Command> print n; N : 1
The following example creates a function that returns the salary of the employee whose employee ID is specified as input, then calls the function and displays the result that was returned.
Command> CREATE OR REPLACE FUNCTION get_sal
(p_id employees.employee_id%TYPE) RETURN NUMBER IS
v_sal employees.salary%TYPE := 0;
BEGIN
SELECT salary INTO v_sal FROM employees
WHERE employee_id = p_id;
RETURN v_sal;
END get_sal;
/
Function created.
Command> variable n number;
Command> call get_sal(100) into :n;
Command> print n;
N : 24000COMMIT
The COMMIT statement ends the current transaction and makes permanent all changes performed in the transaction.
Required privilege
None
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
COMMIT [WORK]
Parameters
The COMMIT statement enables the following optional keyword:
| Parameter | Description |
|---|---|
|
|
Optional clause supported for compliance with the SQL standard. |
Description
-
Until you commit a transaction:
-
You can see any changes you have made during the transaction but other users cannot see the changes. After you commit the transaction, the changes are visible to other users' statements that execute after the commit.
-
You can roll back (undo) changes made during the transaction with the
ROLLBACKstatement.
-
-
This statement releases transaction locks.
-
For passthrough, the Oracle Database transaction will also be committed.
-
A commit closes all open cursors.
Examples
Insert a row into regions table of the HR schema and commit transaction. First set autocommit to 0:
Command> SET AUTOCOMMIT 0; Command> INSERT INTO regions VALUES (5,'Australia'); 1 row inserted. Command> COMMIT; Command> SELECT * FROM regions; < 1, Europe > < 2, Americas > < 3, Asia > < 4, Middle East and Africa > < 5, Australia > 5 rows found.
See also
CREATE ACTIVE STANDBY PAIR
This statement is not supported in TimesTen Scaleout.
In TimesTen Classic:
This statement creates an active standby pair. It includes an active master database, a standby master database, and may also include one or more read-only subscribers. The active master database replicates updates to the standby master database, which propagates the updates to the subscribers.
Required privilege
ADMIN
Usage with TimesTen Scaleout
This statement is not supported with TimesTen Scaleout.
SQL syntax
CREATE ACTIVE STANDBY PAIR FullStoreName, FullStoreName [ReturnServiceAttribute] [SUBSCRIBER FullStoreName [,...]] [STORE FullStoreName [StoreAttribute [...]]] [NetworkOperation [...] ] [{ INCLUDE | EXCLUDE }{TABLE [[Owner.]TableName [,...]]| CACHE GROUP [[Owner.]CacheGroupName [,...]]| SEQUENCE [[Owner.]SequenceName [,...]]} [,...]]
Syntax for ReturnServiceAttribute:
{ RETURN RECEIPT [BY REQUEST] |
RETURN TWOSAFE [BY REQUEST] |
NO RETURN }
Syntax for StoreAttribute:
DISABLE RETURN {SUBSCRIBER | ALL} NumFailures
RETURN SERVICES {ON | OFF} WHEN [REPLICATION] STOPPED
DURABLE COMMIT {ON | OFF}
RESUME RETURN Milliseconds
LOCAL COMMIT ACTION {NO ACTION | COMMIT}
RETURN WAIT TIME Seconds
COMPRESS TRAFFIC {ON | OFF}
PORT PortNumber
TIMEOUT Seconds
FAILTHRESHOLD Value
TABLE DEFINITION CHECKING {RELAXED|EXACT}
Syntax for NetworkOperation:
ROUTE MASTER FullStoreName SUBSCRIBER FullStoreName { { MASTERIP MasterHost | SUBSCRIBERIP SubscriberHost } PRIORITY Priority } [...]
Parameters
| Parameter | Description |
|---|---|
|
|
The database, specified as one of the following:
For example, if the database path is This is the database file name specified in the
|
|
|
Enables the return receipt service, so that applications that commit a transaction to an active master database are blocked until the transaction is received by the standby master database. Specifying |
|
|
Enables the return twosafe service, so that applications that commit a transaction to an active master database are blocked until the transaction is committed on the standby master database. Specifying For details on the use of the return services, see "Using a return service" in Oracle TimesTen In-Memory Database Replication Guide. |
|
|
Set the return service failure policy so that return service blocking is disabled after the number of timeouts specified by Specifying This failure policy can be specified for either the |
|
|
Sets return services on or off when replication is disabled (stopped or paused state).
See "Establishing return service failure/recovery policies" in Oracle TimesTen In-Memory Database Replication Guide. |
|
|
If |
|
|
Specifies that no return service is to be used. This is the default. For details on the use of the return services, see "Using a return service" in Oracle TimesTen In-Memory Database Replication Guide. |
|
|
Specifies the number of seconds to wait for return service acknowledgment. A value of 0 (zero) means that there is no waiting. The default value is 10 seconds. The application can override this timeout setting by using the |
|
|
A database that receives updates from a master database. |
|
|
Defines the attributes for the specified database. Attributes include |
|
|
StoreAttribute clause. Specifies type of table definition checking that occurs on the subscriber:
The default is Note: If you use |
|
|
An active standby pair replicates an entire database by default.
Do not use the |
|
|
Compress replicated traffic to reduce the amount of network bandwidth. |
|
|
Overrides the |
|
|
The number of log files that can accumulate for a subscriber database. If this value is exceeded, the subscriber is set to the See "Setting the transaction log failure threshold" in Oracle TimesTen In-Memory Database Replication Guide for more information. |
|
|
Specifies the default action to be taken for a return twosafe transaction in the event of a timeout. Note: This attribute is valid only when the
This setting can be overridden for specific transactions by calling the |
|
|
The database on which applications update the specified element. The |
|
|
The TCP/IP port number on which the replication agent for the database listens for connections. If not specified, the replication agent automatically allocates a port number. In an active standby pair, the standby master database listens for updates from the active master database. Read-only subscribers listen for updates from the standby master database. |
|
|
Denotes the
When using active standby pairs, For |
|
|
Clause can be specified more than once. |
|
|
Variable expressed as an integer from 1 to 99. Denotes the priority of the IP address. Lower integral values have higher priority. An error is returned if multiple addresses with the same priority are specified. Controls the order in which multiple IP addresses are used to establish peer connections. Required syntax of |
|
|
The maximum number of seconds the replication agent waits for a response from remote replication agents. The default is 120 seconds. In an active standby pair, the active master database sends messages to the standby master database. The standby master database sends messages to the read-only subscribers. Note: For large transactions that may cause a delayed response from the remote replication agent, the agent scales the timeout based on the size of the transaction. This scaling is disabled if you set |
Description
-
After you create an active standby pair, make one of your databases the active database. To accomplish this, call
ttRepStateSet('ACTIVE'). Then usettRepAdminto duplicate the active database to the second database. When the operation is successful, the second database becomes the standby database. For more information, see "Setting up an active standby pair with no cache groups" in Oracle TimesTen In-Memory Database Replication Guide. -
The
SUBSCRIBERclause lists one or more read-only subscriber databases. You can designate up to 127 subscriber databases. -
Replication between the active master database and the standby master database can be
RETURN TWOSAFE,RETURN RECEIPT, or asynchronous.RETURN TWOSAFEensures no transaction loss. -
Use the
INCLUDEandEXCLUDEclauses to exclude the listed tables, sequences and cache groups from replication, or to include only the listed tables, sequences and cache groups, excluding all others. -
If the active standby pair has the
RETURN TWOSAFEattribute and replicates a cache group, a transaction may fail if:-
The transaction that is being replicated contains an
ALTER TABLEstatement or anALTER CACHE GROUPstatement. -
The transaction contains an
INSERT,UPDATEorDELETEstatement on a replicated table, replicated cache group or an asynchronous writethrough cache group.
-
-
You can use an active standby pair to replicate read-only cache groups and asynchronous writethrough (AWT) cache groups. You cannot use an active standby pair to replicate synchronous writethrough (SWT) cache groups or user managed cache groups.
-
You cannot use the
EXCLUDEclause for AWT cache groups. -
You cannot execute the
CREATE ACTIVE STANDBY PAIRstatement when Oracle Clusterware is used with TimesTen.
Examples
This example creates an active standby pair whose master databases are rep1 and rep2. There is one subscriber, rep3. The type of replication is RETURN RECEIPT. The statement also sets PORT and TIMEOUT attributes for the master databases.
CREATE ACTIVE STANDBY PAIR rep1, rep2 RETURN RECEIPT SUBSCRIBER rep3 STORE rep1 PORT 21000 TIMEOUT 30 STORE rep2 PORT 22000 TIMEOUT 30;
Specify NetworkOperation clause to control network interface:
CREATE ACTIVE STANDBY PAIR rep1,rep2 ROUTE MASTER rep1 ON "machine1" SUBSCRIBER rep2 ON "machine2" MASTERIP "1.1.1.1" PRIORITY 1 SUBSCRIBERIP "2.2.2.2" PRIORITY 1; ROUTE MASTER rep2 ON "machine2" SUBSCRIBER rep1 ON "machine1" MASTERIP "2.2.2.2" PRIORITY 1 SUBSCRIBERIP "1.1.1.1" PRIORITY 1;
CREATE CACHE GROUP
The CREATE CACHE GROUP statement:
-
Creates the table defined by the cache group.
-
Loads all new information associated with the cache group in the appropriate system tables.
A cache group is a set of tables related through foreign keys that cache data from tables in an Oracle database. There is one root table that does not reference any of the other tables. All other cache tables in the cache group reference exactly one other table in the cache group. In other words, the foreign key relationships form a tree.
A cache table is a set of rows satisfying the conditions:
-
The rows constitute a subset of the rows of a vertical partition of an Oracle database table.
-
The rows are stored in a TimesTen table with the same name as the Oracle database table.
If a database has more than one cache group, the cache groups must correspond to different Oracle database (and TimesTen) tables.
Cache group instance refers to a row in the root table and all the child table rows related directly or indirectly to the root table rows.
A cache group can be either system managed or user managed.
A system managed cache group is fully managed by TimesTen and has fixed properties. System managed cache group types include:
-
Read-only cache groups are updated in the Oracle database, and the updates are propagated from the Oracle database to the cache.
-
Asynchronous writethrough (AWT) cache groups are updated in the cache and the updates are propagated to the Oracle database. Transactions continue executing on the cache without waiting for a commit on the Oracle database.
-
Synchronous writethrough (SWT) cache groups are updated in the cache and the updates are propagated to the Oracle database. Transactions are committed on the cache after notification that a commit has occurred on the Oracle database.
Because TimesTen manages system managed cache groups, including loading and unloading the cache group, certain statements and clauses cannot be used in the definition of these cache groups, including:
-
WHEREclauses in AWT and SWT cache group definitions -
READONLY,PROPAGATEandNOT PROPAGATEin cache table definitions -
AUTOREFRESHin AWT and SWT cache group definitions
The FLUSH CACHE GROUP and REFRESH CACHE GROUP operations are not allowed for AWT and SWT cache groups.
You must stop the replication agent before creating an AWT cache group.
A user managed cache group must be managed by the application or user. PROPAGATE in a user managed cache group is synchronous. The table-level READONLY keyword can only be used for user managed cache groups.
In addition, both TimesTen and Oracle Database must be able to parse all WHERE clauses.
Cache groups can be explicitly or dynamically loaded.
In cache groups that are explicitly loaded, new cache instances are loaded manually into the TimesTen cache tables from the Oracle database tables using a LOAD CACHE GROUP or REFRESH CACHE GROUP statement or automatically using an autorefresh operation.
In a dynamic cache group, new cache instances can be loaded manually into the TimesTen cache tables by using a LOAD CACHE GROUP or on demand using a dynamic load operation. In a dynamic load operation, data is automatically loaded into the TimesTen cache tables from the cached Oracle database tables when a SELECT, UPDATE, DELETE or INSERT statement is issued on one of the cache tables, where the data is not present in the cache table but does exist in the cached Oracle database table. A manual refresh or automatic refresh operation on a dynamic cache group can result in the updating or deleting of existing cache instances, but not in the loading of new cache instances.
Any cache group type (read-only, asynchronous writethrough, synchronous writethrough, user managed) can be defined as an explicitly loaded cache group.
Any cache group type can be defined as a dynamic cache group except a user managed cache group that has both the AUTOREFRESH cache group attribute and the PROPAGATE cache table attribute.
Data in a dynamic cache group is aged out because LRU aging is defined by default. Use the ttAgingLRUConfig and/or the ttAgingTableLRUConfig built-in procedures to override the space usage thresholds for LRU aging. You can also define time-based aging on a dynamic cache group to override LRU aging.
For more information on static and dynamic cache groups, see "Cache groups and cache tables" in Oracle TimesTen In-Memory Database Cache Guide.
Required privilege
CREATE CACHE GROUP or CREATE ANY CACHE GROUP and CREATE TABLE (if all tables in the cache group are owned by the current user) or CREATE ANY TABLE (if at least one of the tables in the cache group is not owned by the current user).
Usage with TimesTen Scaleout
Static read-only cache groups with incremental autorefresh are supported.
SQL syntax: TimesTen Scaleout
CREATE READONLY CACHE GROUP [Owner.]GroupName
[AUTOREFRESH
[MODE INCREMENTAL]
[INTERVAL IntervalValue {MINUTE[S] | SECOND[S] | MILLISECOND[S]}]
[STATE {ON|OFF|PAUSED}]
]
FROM
[Owner.]TableName (ColumnDefinition[,...][,PRIMARY KEY(ColumnName[,...])])
[UNIQUE HASH ON (HashColumnName[,...]) PAGES=PrimaryPages]
[ParentDistributionClause]
[WHERE ExternalSearchCondition]
[,[Owner.]TableName (ColumnDefinition[,...]
[,PRIMARY KEY(ColumnName[,...])]
[,FOREIGN KEY(ColumnName[,...])
REFERENCES RefTableName (ColumnName [,...])[ON DELETE CASCADE]])
[UNIQUE HASH ON (HashColumnName[,...]) PAGES=PrimaryPages]
[ChildDistributionClause]
[WHERE ExternalSearchCondition]
[,...]
]
The syntax for the distribution clause for a parent:
ParentDistributionClause::= DISTRIBUTE BY HASH [(ColumnName [,...])] | DUPLICATE
The syntax for the distribution clause for a child:
ChildDistributionClause::= DISTRIBUTE BY HASH [(ColumnName [,...])] |
DISTRIBUTE BY REFERENCE [(ForeignKeyConstraint)] | DUPLICATESQL syntax: TimesTen Classic
For read-only cache groups:
CREATE [DYNAMIC] [HYBRID] READONLY CACHE GROUP [Owner.]GroupName [AUTOREFRESH [MODE {INCREMENTAL | FULL}] [INTERVAL IntervalValue {MINUTE[S] | SECOND[S] | MILLISECOND[S] }] [STATE {ON|OFF|PAUSED}] ] FROM [Owner.]TableName ( {ColumnDefinition[,...]} [,PRIMARY KEY(ColumnName[,...])] [,FOREIGN KEY(ColumnName [,...]) REFERENCES RefTableName (ColumnName [,...])] [ON DELETE CASCADE]) [UNIQUE HASH ON (HashColumnName[,...]) PAGES=PrimaryPages] [AGING {LRU| USE ColumnName LIFETIME Num1 {SECOND[S] | MINUTE[S] |HOUR[S] |DAY[S]} [CYCLE Num2 {SECOND[S] | MINUTE[S] |HOUR[S] |DAY[S]}] }[ON|OFF] ] [WHERE ExternalSearchCondition] } [,...]
For asynchronous writethrough cache groups:
CREATE [DYNAMIC] [ASYNCHRONOUS] WRITETHROUGH CACHE GROUP [Owner.]GroupName FROM {[Owner.]TableName ( {ColumnDefinition[,...]} [,PRIMARY KEY(ColumnName[,...])] [FOREIGN KEY(ColumnName [,...]) REFERENCES RefTableName (ColumnName [,...])] [ON DELETE CASCADE]) UNIQUE HASH ON (HashColumnName[,...]) PAGES=PrimaryPages] [AGING {LRU| USE ColumnName LIFETIME Num1 {SECOND[S] | MINUTE[S] |HOUR[S] |DAY[S]} [CYCLE Num2 {SECOND[S] | MINUTE[S] |HOUR[S] |DAY[S]}] }[ON|OFF] ] } [,...]
For synchronous writethrough cache groups:
CREATE [DYNAMIC] SYNCHRONOUS WRITETHROUGH CACHE GROUP [Owner.]GroupName FROM {[Owner.]TableName ( {ColumnDefinition[,...]} [,PRIMARY KEY(ColumnName[,...])] [FOREIGN KEY(ColumnName [,...]) REFERENCES RefTableName (ColumnName [,...])] [ON DELETE CASCADE]) [UNIQUE HASH ON (HashColumnName[,...]) PAGES=PrimaryPages] [AGING {LRU| USE ColumnName LIFETIME Num1 {SECOND[S] | MINUTE[S] |HOUR[S] |DAY[S]} [CYCLE Num2 {SECOND[S] | MINUTE[S] |HOUR[S] |DAY[S]}] }[ON|OFF] ] } [,...]
For user managed cache groups:
CREATE [DYNAMIC][USERMANAGED] CACHE GROUP [Owner.]GroupName [AUTOREFRESH [MODE {INCREMENTAL | FULL}] [INTERVAL IntervalValue {MINUTE[S] | SECOND[S] | MILLISECOND[S] }] [STATE {ON|OFF|PAUSED}] ] FROM {[Owner.]TableName ( {ColumnDefinition[,...]} [,PRIMARY KEY(ColumnName[,...])] [FOREIGN KEY(ColumnName[,...]) REFERENCES RefTableName (ColumnName [,...])] [ON DELETE CASCADE] [,{READONLY | PROPAGATE | NOT PROPAGATE}]) [UNIQUE HASH ON (HashColumnName[,...]) PAGES=PrimaryPages] [AGING {LRU| USE ColumnName LIFETIME Num1 {SECOND[S] | MINUTE[S] |HOUR[S] |DAY[S]} [CYCLE Num2 {SECOND[S] | MINUTE[S] |HOUR[S] |DAY[S]}] }[ON|OFF] ] [WHERE ExternalSearchCondition] } [,...]
Parameters
Following are the parameters for the cache group definition before the FROM keyword:
| Parameter | Description |
|---|---|
|
|
Owner and name assigned to the new cache group. |
|
|
Supported in TimesTen Classic only. If specified, a dynamic cache group is created. |
HYBRID |
Supported in TimesTen Classic only. If specified, a dynamic read-only cache group where the root table does not exist in the Oracle database. |
|
|
The |
|
|
Determines which rows in the cache are updated during an autorefresh. If the In TimesTen Scaleout, |
|
|
Indicates the interval at which autorefresh should occur in units of minutes, seconds or milliseconds. If the specified interval is not long enough for an autorefresh to complete, a runtime warning is generated and the next autorefresh waits until the current one finishes. An informational message is generated in the support log if the wait queue reaches 10. |
|
|
Specifies whether autorefresh should be |
|
|
Designates one or more table definitions for the cache group. |
Everything after the FROM keyword comprises the definitions of the Oracle database tables cached in the cache group. The syntax for each table definition is similar to that of a CREATE TABLE statement. However, primary key constraints are required for the cache group table.
Table definitions have the following parameters.
| Parameter | Description |
|---|---|
|
|
Owner and name to be assigned to the new table. If you do not specify the owner name, your login becomes the owner name for the new table. |
|
|
Name of an individual column in a table, its data type and whether it is nullable. Each table must have at least one column. |
|
|
Specifies that the table has a primary key. Primary key constraints are required for a cache group. |
|
|
Specifies that the table has a foreign key. |
|
|
Specifies the table which the foreign key is associated with. |
|
|
Enables the |
|
|
Specifies that changes cannot be made on the cached table. |
|
|
Supported in TimesTen Classic only. Specifies whether changes to the cached table are automatically propagate to the corresponding Oracle database table at commit time. |
|
|
Specifies that a hash index is created on this table. |
|
|
Sizes the hash index to reflect the expected number of pages in your table. To determine the value for The value for If your estimate for For more information on hash indexes, see "CREATE TABLE". |
|
|
The |
|
|
In TimesTen Scaleout, distribution clause for a parent table in a static read-only cache group with incremental autorefresh. These distribution schemes are supported for parent tables:
|
|
|
In TimesTen Scaleout, distribution clause for a child table in a static read-only cache group with incremental autorefresh. These distribution schemes are supported for child tables:
|
|
|
Supported in TimesTen Classic only. If specified, defines the LRU aging policy on the root table. The LRU aging policy applies to all tables in the cache group. The LRU aging policy defines the type of aging (least recently used (LRU)), the aging state ( Set the aging state to either In dynamic cache groups, LRU aging is LRU aging cannot be specified on a cache group with the autorefresh attribute, unless the cache group is dynamic. LRU attributes are defined by calling the |
|
|
Supported in TimesTen Classic only. If specified, defines the time-based aging policy on the root table. The time-based aging policy applies to all tables in the cache group. The time-based aging policy defines the type of aging (time-based), the aging state ( Set the aging state to either Time-based aging attributes are defined at the SQL level and are specified by the Specify The values of the column used for aging are updated by your applications. If the value of this column is unknown for some rows, and you do not want the rows to be aged, define the column with a large default value (the column cannot be For more information about time-based aging, see "Implementing aging in a cache group for TimesTen Classic" in Oracle TimesTen In-Memory Database Cache Guide. |
|
|
Supported in TimesTen Classic only.
Specify the The Specify The concept of time resolution is supported. If |
|
|
Supported in TimesTen Classic only.
The Specify If you do not specify the If the aging state is |
Cache groups in TimesTen Scaleout
TimesTen Scaleout supports static read-only cache groups with incremental autorefresh. You can specify a distribution scheme on a parent table and on one or more child tables. The distribution scheme specifies how data is distributed across the elements of the database.
DISTRIBUTE BY clause:
- For a single table cache group, the default distribution scheme is
HASH. - If you do not specify a column in the
DISTRIBUTEBYclause, the primary key columns are used as the key columns for the distribution scheme. - For a multiple table cache group, you can specify either the
HASHor theDUPLICATEdistribution scheme on the parent table. If you define theDUPLICATEdistribution scheme, you can only specifyHASHorDUPLICATEon the child tables. - For a multiple table cache group,
HASHis the default distribution scheme for the parent table and all child tables default to theREFERENCEdistribution scheme. If you specifyDUPLICATEon the parent table, and do not specify a distribution scheme for the child tables, the default distribution scheme for the child tables isDUPLICATE. - If the foreign key on a child table is identical to the primary key on the parent table, the
HASHdistribution scheme is used for the child table as an optimization. - It is best practice to distribute child tables by reference.
See "Distribution schemes for TimesTen Cache in TimesTen Scaleout" in the Oracle TimesTen In-Memory Database Scaleout User's Guide for more information on distribution schemes.
- Full autorefresh mode
- Aging
- Materialized views
- Global indexes
For more information on static read-only cache groups in TimesTen Scaleout, see "Using Cache Groups in TimesTen Scaleout" in the Oracle TimesTen In-Memory Database Scaleout User's Guide.
Cache groups in TimesTen Classic
Dynamic hybrid read-only cache groups
A dynamic hybrid read-only cache group is a dynamic read-only cache group where the root table does not exist in the Oracle database. The root table is automatically created in the TimesTen database from the cache group definition. The cache group definition includes the description of this root table, as if it existed in the Oracle database.
- The root table must not exist in the Oracle database.
- The root table in the TimesTen database must have a primary key.
- The root table can only contain columns in the primary key. The primary key must be referenced by at least one child table.
- For dynamic load triggering, you can use a derived table in the
FROMclause of theSELECTstatement. You can also specify more than one table of the same hybrid cache group in theSELECTquery. - If you issue a
SELECTquery on the root table in the TimesTen database, thisSELECToperation does not trigger a dynamic load. - You cannot specify time-based aging on this type of cache group. LRU aging is enabled by default.
- The
WHEREclause in the cache group definition is not supported. - You cannot use the
LOADCACHEGROUPstatement to manually load the cache group. - The
UNLOADCACHE GROUP ...WITH IDstatement is not supported.
See "Hybrid cache group" in the Oracle TimesTen In-Memory Database Cache Guide for more information on dynamic hybrid read-only cache groups.
Description of cache groups
-
Two cache groups cannot have the same owner name and group name. If you do not specify the owner name, your schema becomes the owner name for the new cache group.
-
Neither a cache table name nor a cache group name can contain #.
-
Dynamic parameters are not allowed in the
WHEREclause. -
Oracle Database temporary tables cannot be cached.
-
Each table must correspond to a table in the Oracle database.
-
In the Oracle database, you can define a parent/child relationship and then insert a null value into the foreign key column of the child table. This means this row in the child table references a null parent. You can then create a cache group and cache the parent/child relationship of the Oracle database tables. However, if you load data from the Oracle database tables into the cache group, the row that contains the null value of the foreign key column is not loaded. TimesTen recommends that you do not create cache groups if the tables you cache define a parent/child relationship in which the foreign key represents a null parent.
-
You cannot use lowercase delimited identifiers to name your cache tables. Table names in TimesTen are case-insensitive and are stored as uppercase. The name of the cache table must be the same as the Oracle database table name. Uppercase table names on TimesTen will not match mixed case table names on the Oracle database. As a workaround, create a synonym for your table in the Oracle database and use that synonym as the table name for the cache group. This workaround is not available for read-only cache groups or cache groups with the
AUTOREFRESHparameter set. -
Each column in the cache table must match each column in the Oracle database table, both in name and in data type. See "Mappings between Oracle Database and TimesTen data types" in Oracle TimesTen In-Memory Database Cache Guide. In addition, each column name must be fully qualified with an owner and table name when referenced in a
WHEREclause. -
The
WHEREclause can only directly refer to the cache group table. Tables that are not in the cache group can only be referenced with a subquery. -
Generally, you do not have to fully qualify the column names in the
WHEREclause of theCREATE CACHE GROUP,LOAD CACHE GROUP,UNLOAD CACHE GROUP,REFRESH CACHE GROUPorFLUSH CACHE GROUPstatements. However, since TimesTen automatically generates queries that join multiple tables in the same cache group, a column must be fully qualified if there is more than one table in the cache group that contains columns with the same name. -
By default, a range index is created to enforce the primary key for a cache group table. Use the
UNIQUE HASHclause if you want to specify a hash index for the primary key.-
If your application performs range queries over a cache group table's primary key, then choose a range index for that cache group table by omitting the
UNIQUE HASHclause. -
If, however, your application performs only exact match lookups on the primary key, then a hash index may offer better response time and throughput. In such a case, specify the
UNIQUE HASHclause. See "CREATE TABLE" for more information on theUNIQUE HASHclause. -
Use
ALTER TABLEto change the representation of the primary key index for a table.
-
-
For cache group tables with the
PROPAGATEattribute and for tables of SWT and AWT cache groups, foreign keys specified withON DELETE CASCADEmust be a proper subset of foreign keys withON DELETE CASCADEin the Oracle database tables. -
You cannot execute the
CREATE CACHE GROUPstatement when performed under the serializable isolation level. An error message is returned when attempted.
The AUTOREFRESH parameter automatically propagates changes from the Oracle database to TimesTen cache groups. For static cache groups, deletes, updates and inserts are automatically propagated from the Oracle database to the cache group. For dynamic cache groups, only deletes and updates are propagated. Inserts to the specified Oracle database tables are not propagated to dynamic cache groups. They are dynamically loaded into TimesTen Cache when referenced by the application. They can also be explicitly loaded by the application.
To use autorefresh with a cache group, you must specify AUTOREFRESH when you create the cache group. You can change the MODE, STATE and INTERVAL AUTOREFRESH settings after a cache group has been created by using the ALTER CACHE GROUP statement. Once a cache group has been specified as either AUTOREFRESH or PROPAGATE, you cannot change these attributes. If you are creating a read-only cache group, you do not need to specify the autorefresh clause. A read-only cache group defaults to incremental autorefresh.
TimesTen supports FULL or INCREMENTAL AUTOREFRESH. In FULL mode, the entire cache is periodically unloaded and then reloaded. In INCREMENTAL mode, TimesTen installs triggers in the Oracle database to track changes and periodically updates only the rows that have changed in the specified Oracle database tables. The first incremental refresh is always a full refresh, unless the autorefresh state is PAUSED. The default mode is INCREMENTAL.
FULL AUTOREFRESH is more efficient when most of the Oracle database table rows have been changed. INCREMENTAL AUTOREFRESH is more efficient when there are fewer changes.
TimesTen schedules an autorefresh operation when the transaction that contains a statement with AUTOREFRESH specified is committed. The statement types that cause autorefresh to be scheduled are:
-
A
CREATE CACHE GROUPstatement in whichAUTOREFRESHis specified, and theAUTOREFRESHstate is specified asON. -
An
ALTER CACHE GROUPstatement in which theAUTOREFRESHstate has been changed toON. -
A
LOAD CACHE GROUPstatement on an empty cache group whose autorefresh state isPAUSED.
The specified interval determines how often autorefresh occurs.
The current STATE of AUTOREFRESH can be ON, OFF or PAUSED. By default, the autorefresh state is PAUSED.
The NOT PROPAGATE attribute cannot be used with the AUTOREFRESH attribute.
Aging in cache groups:
-
You can implement sliding windows with time-based aging. See "Configuring a sliding window in TimesTen Classic" in Oracle TimesTen In-Memory Database Cache Guide.
-
After you have defined an aging policy for the table, you cannot change the policy from LRU to time-based or from time-based to LRU. You must first drop aging and then alter the table to add a new aging policy.
-
The aging policy must be defined to change the aging state.
-
LRU and time-based aging can be combined in one system. If you use only LRU aging, the aging thread wakes up based on the cycle specified for the whole database. If you use only time-based aging, the aging thread wakes up based on an optimal frequency. This frequency is determined by the values specified in the
CYCLEclause for the database. If you use both LRU and time-based aging, then the thread wakes up based on a combined consideration of both types. -
Call the
ttAgingScheduleNowprocedure to schedule the aging process right away regardless if the aging state isONorOFF. -
The following rules determine if a row is accessed or referenced for LRU aging:
-
Any rows used to build the result set of a
SELECTstatement. -
Any rows used to build the result set of an
INSERT...SELECTstatement. -
Any rows that are about to be updated or deleted.
-
-
Compiled commands are marked invalid and need recompilation when you either drop LRU aging from or add LRU aging to tables that are referenced in the commands.
- use
For LRU aging, if a child row is not a candidate for aging, then neither this child row nor its parent row are deleted.
ON DELETE CASCADEsettings are ignored. -
For time-based aging, if a parent row is a candidate for aging, then all child rows are deleted.
ON DELETE CASCADE(whether specified or not) is ignored. -
Specify either the LRU aging or time-based aging policy on the root table. The policy applies to all tables in the cache group.
-
For the time-based aging policy, you cannot add or modify the aging column. This is because you cannot add or modify a
NOT NULLcolumn. -
Restrictions on defining aging for a cache group:
-
LRU aging is not supported on a cache group defined with the autorefresh attribute, unless it is a dynamic cache group.
-
The aging policy cannot be added, altered, or dropped for read-only cache groups or cache groups with the
AUTOREFRESHattribute while the cache agent is active. Stop the cache agent first. -
You cannot drop the column that is used for time-based aging.
-
Examples: TimesTen Classic
These examples are specific to TimesTen Classic. For information and examples on using cache groups in TimesTen Scaleout, see "Using Cache Groups in TimesTen Scaleout" in the Oracle TimesTen In-Memory Database Scaleout User's Guide.
Create a read-only cache group:
CREATE READONLY CACHE GROUP customerorders AUTOREFRESH INTERVAL 10 MINUTES FROM customer (custid INT NOT NULL, name CHAR(100) NOT NULL, addr CHAR(100), zip INT, region CHAR(10), PRIMARY KEY(custid)), ordertab (orderid INT NOT NULL, custid INT NOT NULL, PRIMARY KEY (orderid), FOREIGN KEY (custid) REFERENCES customer(custid));
Create an asynchronous writethrough cache group:
CREATE ASYNCHRONOUS WRITETHROUGH CACHE GROUP cstomers FROM customer (custid INT NOT NULL, name CHAR(100) NOT NULL, addr CHAR(100), zip INT, PRIMARY KEY(custid));
Create a synchronous writethrough cache group:
CREATE SYNCHRONOUS WRITETHROUGH CACHE GROUP customers FROM customer (custid INT NOT NULL, name CHAR(100) NOT NULL, addr CHAR(100), zip INT, PRIMARY KEY(custid));
Create a user managed cache group:
CREATE USERMANAGED CACHE GROUP updateanywherecustomers AUTOREFRESH MODE INCREMENTAL INTERVAL 30 SECONDS STATE ON FROM customer (custid INT NOT NULL, name CHAR(100) NOT NULL, addr CHAR(100), zip INT, PRIMARY KEY(custid), PROPAGATE);
Create a cache group with time-based aging. Specify agetimestamp as the column for aging. Specify LIFETIME 2 hours, CYCLE 30 minutes. Aging state is not specified, so the default setting (ON) is used.
CREATE READONLY CACHE GROUP agingcachegroup AUTOREFRESH MODE INCREMENTAL INTERVAL 5 MINUTES STATE PAUSED FROM customer (customerid NUMBER NOT NULL, agetimestamp TIMESTAMP NOT NULL, PRIMARY KEY (customerid)) AGING USE agetimestamp LIFETIME 2 HOURS CYCLE 30 MINUTES; Command> DESCRIBE customer; Table USER.CUSTOMER: Columns: *CUSTOMERID NUMBER NOT NULL AGETIMESTAMP TIMESTAMP (6) NOT NULL AGING USE AgeTimestamp LIFETIME 2 HOURS CYCLE 30 MINUTES ON 1 table found. (primary key columns are indicated with *)
Use a synonym for a mixed case delimited identifier table name in the Oracle database so the mixed case table name can be cached in TimesTen. First attempt to cache the mixed case Oracle database table name. You see the error "Could not find 'NameofTable' in Oracle":
Command> AUTOCOMMIT 0; Command> PASSTHROUGH 3; Command> CREATE TABLE "MixedCase" (col1 NUMBER PRIMARY KEY NOT NULL); Command> INSERT INTO "MixedCase" VALUES (1); 1 row inserted. Command> COMMIT; Command> CREATE CACHE GROUP MixedCase1 from "MixedCase" (col1 NUMBER PRIMARY KEY NOT NULL); 5140: Could not find SAMPLEUSER.MIXEDCASE in Oracle. May not have privileges. The command failed.
Now, using the PassThrough attribute, create the synonym "MIXEDCASE" in the Oracle database and use that synonym as the table name.
Command> AUTOCOMMIT 0; Command> PASSTHROUGH 3; Command> CREATE SYNONYM "MIXEDCASE" FOR "MixedCase"; Command> COMMIT; Command> CREATE CACHE GROUP MixedCase2 FROM "MIXEDCASE" (col1 NUMBER PRIMARY KEY NOT NULL); Warning 5147: Cache group contains synonyms Command> COMMIT;
Attempt to use a synonym name with a read-only cache group or a cache group with the AUTOREFRESH attribute. You see an error:
Command> AUTOCOMMIT 0; Command> PASSTHROUGH 3; Command> CREATE SYNONYM "MIXEDCASE_AUTO" FOR "MixedCase"; Command> COMMIT; Command> CREATE READONLY CACHE GROUP MixedCase3 AUTOREFRESH MODE INCREMENTAL INTERVAL 10 MINUTES FROM "MIXEDCASE_AUTO" (Col1 NUMBER PRIMARY KEY NOT NULL); 5142: Autorefresh is not allowed on cache groups with Oracle synonyms The command failed.
CREATE FUNCTION
The CREATE FUNCTION statement creates a standalone stored function.
Required privilege
CREATE PROCEDURE (if owner) or CREATE ANY PROCEDURE (if not owner).
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
CREATE [OR REPLACE] FUNCTION [Owner.]FunctionName[(arguments [IN|OUT|IN OUT][NOCOPY] DataType [DEFAULT expr][,...])] RETURN DataType [InvokerRightsClause][AccessibleByClause][DETERMINISTIC] {IS|AS} PlsqlFunctionBody InvokerRightsClause::= AUTHID {CURRENT_USER|DEFINER} AccessibleByClause::= ACCESSIBLE BY (accessor[,...])accessor::= [UnitKind][Owner.]UnitName
You can specify InvokerRightsClause, AccessibleByClause, or DETERMINISTIC in any order.
Parameters
| Parameter | Description |
|---|---|
|
|
Specify |
|
|
Name of function. |
|
|
Name of argument or parameter. You can specify 0 or more parameters for the function. If you specify a parameter, you must specify a data type for the parameter. The data type must be a PL/SQL data type. |
|
|
Parameter modes.
|
|
|
Specify |
|
|
Use this clause to specify a default value for the parameter. You can specify |
|
|
Required clause. A function must return a value. You must specify the data type of the return value of the function. Do not specify a length, precision, or scale for the data type. The data type is a PL/SQL data type. |
|
|
Lets you specify whether the SQL statements in PL/SQL functions or procedures execute with definer's or invoker's rights. The
For more information, see "Definer's rights and invoker's rights (AUTHID clause)" in the Oracle TimesTen In-Memory Database Security Guide. |
|
|
Use this clause to specify one or more accessors (PL/SQL units) that can invoke the function directly. The list of accessors that can access the function is called a white list. A white list gives you the ability to add an extra layer of security to your PL/SQL objects. Specifically, you can restrict access to the function to only those objects on the white list.
Syntax: |
|
|
Used in An accessor can appear more than once in the Syntax: |
|
|
Used in the
|
|
|
Used in the You can optionally specify |
|
|
Specify |
|
|
Specify either |
|
|
Specifies the function body. |
Description
-
AccessibleByClause:-
The compiler checks the validity of the syntax of the
ACCESSIBLEBYclause, but does not check that the accessor exists. Therefore, you can define an accessor that does yet exist in the owner's schema. -
When you invoke the function, the compiler first does the normal permission checks on the invocation. If any check fails, the invocation fails, even if the invoker is an accessor. If all normal permission checks on the invocation succeed, and the function has no
ACCESSIBLEBYclause, the invocation succeeds. If the function has anACCESSIBLEBYclause, the invocation succeeds only if the invoker is an accessor.
-
-
When you create or replace a function, the privileges granted on the function remain the same. If you drop and recreate the object, the object privileges that were granted on the original object are revoked.
-
In a replication environment, the
CREATE FUNCTIONstatement is not replicated. For more information, see "Creating a new PL/SQL object in an existing active standby pair" and "Adding a PL/SQL object to an existing classic replication scheme" in the Oracle TimesTen In-Memory Database Replication Guide. -
TimesTen does not support:
-
parallel_enable_clauseYou can specify this clause, but it has no effect.
-
call_specclause -
AS EXTERNALclause
-
Examples
Using the AccessibleByClause
This example creates the ProtectedFunction function. The ACCESSIBLE BY clause is used to restrict the invocation of the function to the CallingProc1 and CallingProc2 procedures. Note that for CallingProc1, the type of PL/SQL unit is not specified and for CallingProc2, the type of PL/SQL unit is specified (PROCEDURE).
Command> CREATE OR REPLACE FUNCTION ProtectedFunction (a IN NUMBER)
RETURN NUMBER
ACCESSIBLE BY (CallingProc1, PROCEDURE CallingProc2)
AS
BEGIN
RETURN a * 1;
END;
/
Function created.
Create the CallingProc1 and CallingProc2 procedures.
Command> CREATE OR REPLACE PROCEDURE CallingProc1 AS
a NUMBER:=1;
BEGIN
a:=ProtectedFunction(a);
DBMS_OUTPUT.PUT_LINE ('Calling Procedure: '|| a);
END;
/
Procedure created.
Command> CREATE OR REPLACE PROCEDURE CallingProc2
AS
a NUMBER:=2;
BEGIN
a:=ProtectedFunction(a);
DBMS_OUTPUT.PUT_LINE ('Calling Procedure: '|| a);
END;
/
Procedure created.
Call the procedures. CallingProc1 and CallingProc2 are in the white list, resulting in successful execution.
Command> SET SERVEROUTPUT ON Command> exec CallingProc1; Calling Procedure: 1 PL/SQL procedure successfully completed. Command> exec CallingProc2; Calling Procedure: 2 PL/SQL procedure successfully completed.
Illustrating the syntax for creating a PL/SQL function
Create function get_sal with one input parameter. Return salary as type NUMBER.
Command> CREATE OR REPLACE FUNCTION get_sal
(p_id employees.employee_id%TYPE) RETURN NUMBER IS
v_sal employees.salary%TYPE := 0;
BEGIN
SELECT salary INTO v_sal FROM employees
WHERE employee_id = p_id;
RETURN v_sal;
END get_sal;
/
Function created.CREATE INDEX
The CREATE INDEX statement creates an index on one or more columns of a table or a materialized view.
Required privilege
- If the owner, no privilege is required.
- If not the owner, the
CREATEANYINDEXsystem privilege or theINDEXobject privilege is required.
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout. You can create a global or a local index.
SQL syntax
The syntax to create a range index follows. Use the GLOBAL keyword, the optional INCLUDE clause, and the optional IndexDistributionClause clause to create a global index. A global index is supported only in TimesTen Scaleout:
CREATE [GLOBAL][UNIQUE] INDEX [Owner.]IndexName ON [Owner.]TableName (ColumnName [ASC | DESC][,... ]) [INCLUDE (ColumnName[,…])] [IndexDistributionClause]
The syntax to create a hash index follows. Use the GLOBAL keyword to create a global index. The optional INCLUDE clause, and the optional IndexDistributionClause clause can only be used with a global index. A global index is supported only in TimesTen Scaleout:
CREATE [GLOBAL][UNIQUE] HASH INDEX [Owner.]IndexName ON [Owner.]TableName (ColumnName [ASC | DESC][,... ] ) [INCLUDE (ColumnName [,…])] [ PAGES = RowPages | CURRENT ] [IndexDistributionClause]
The syntax for IndexDistributionClause can only be used for a global index (supported in TimesTen Scaleout):
IndexDistributionClause::= DISTRIBUTE BY HASH [(ColumnName [,…])]
Parameters
| Parameter | Description |
|---|---|
|
|
The In TimesTen Scaleout:
|
|
|
You can specify |
|
|
Specify |
|
|
Name to be assigned to the new index. A table cannot have two indexes with the same name. If the owner is specified, it must be the same as the owner of the table. |
|
|
Designates the table or materialized view for which an index is to be created. |
|
|
Name of a column to be used as an index key. You can specify up to 32 columns in order from major index key to minor index key. |
|
|
Specifies the order of the index to be either ascending (the default) or descending. In TimesTen, this clause is currently ignored. |
|
|
The |
|
|
The If you specify The value for Do not specify |
|
|
You can specify the If you do not specify this clause, the column(s) defined in the global index definition form the distribution key. If you do specify this clause, you can optionally specify the
ColumnName clause:
|
Indexes in TimesTen Scaleout
- Global index: Maps all rows in the table to a hash distribution scheme. When you create a global index, TimesTen Scaleout creates a materialized view with a local index and a hash distribution scheme to the index key columns. The local index that is created on the materialized view further optimizes query performance.
- Local index: Is created in each database element. The index in this database element maps to rows in the table in this database element. Queries on index columns that do not include the distribution key columns on the table require communication with an element in every replica set.
See "Understanding indexes" in the Oracle TimesTen In-Memory Database Scaleout User's Guide for information on using indexes in TimesTen Scaleout.
Choosing a global or a local index in TimesTen Scaleout
-
Use a global index for:
- Unique columns: A global unique index optimizes query execution by performing unique constraint checks more efficiently. TimesTen Scaleout uses the distribution key columns for uniqueness verification instead of accessing all replica sets. However, if the distribution key is a subset of the index key, create a local index.
- Queries that have an equality predicate that do not include all of the columns in the distribution key of the table.
- A group of columns that are frequently joined in queries with primary key columns.
- Non-index columns that are frequently used in queries: Define a global index with the
INCLUDEclause to include those non-index columns. In such a case, the table does not need to be accessed to satisfy the query. - An index where the index key is a prefix of the distribution key of the table.
- Use a local index for:
- Non-unique columns: If the index key consists of only non-unique columns, create a local non-unique index.
- An index key that has the same columns as the distribution key for the table.
- The situation where the distribution key of the table is a prefix of the index key.
- Queries that have an equality predicate that includes all columns in the distribution key of the table.
See "Understanding indexes" in the Oracle TimesTen In-Memory Database Scaleout User's Guide for more information.
Description of global indexes
- You must specify the
GLOBALkeyword to create a global index. An index is local by default. - Global indexes by default are distributed by hash and can only be distributed by hash. Local indexes are not distributed.
- When you create a global index, TimesTen Scaleout internally creates its own materialized view and its own local index on that materialized view.
- Global indexes result in more efficient query execution with joins. However DML operations are slower due to the maintenance of the internal materialized view (that is created when you define a global index).
- When a new element is added in the grid, the schema is replicated on the new element. In addition, the rows are redistributed, and the indexes are rebuilt. This includes the global indexes. Similarly, when an element is removed from the grid, the rows are redistributed and the indexes are rebuilt.
- You can define a global index on a table distributed by hash and on a table distributed by reference. Global indexes on parent and child (first-level reference) tables are supported. However, you cannot define a global index on grandchild tables or any tables that are not first-level reference tables.
- You cannot define a global index on a table distributed by duplicate.
Restrictions on global indexes:
- The column list for the distribution key cannot contain the
ROWIDpseudocolumn or a column of typeROWID. - Not supported on a global temporary table.
- Not supported on readonly cache groups.
- Not supported on a materialized view.
Syntax and semantic rules for global indexes
You must specify the GLOBAL keyword to create a global index. If you do not specify the GLOBAL keyword, a local index is created. Global indexes are distributed by hash on index key columns.
GLOBAL keyword, you can optionally specify these clauses that are specific to global indexes:
INCLUDEclause: Optional clause that enables you to include non-key columns in the index. If such columns are frequently accessed by queries that use the index, this may improve performance.-
IndexDistributionClause: Optional clause that enables you to specify what columns to use for the hash distribution. If you do not specify this clause, then the index columns form the distribution key. The distribution key of the index cannot be the same as the distribution key of the table. -
Examples:
Global range index:
Command> CREATE GLOBAL INDEX globalindex1 ON mytab (a) INCLUDE (b,c) DISTRIBUTE BY HASH (a); Command> indexes mytab; Indexes on table SAMPLEUSER.MYTAB: MYTAB: unique range index on columns: C B GLOBALINDEX1: global non-unique range index on columns: A Included columns: B C 2 indexes found. 2 indexes found on 1 table. Command> drop table mytab;Global hash index:
Command> CREATE TABLE mytab (c TT_INTEGER NOT NULL, b TT_INTEGER NOT NULL, a TT_INTEGER NOT NULL, PRIMARY KEY (c,b)) DISTRIBUTE BY HASH (a,b); Command> CREATE GLOBAL HASH INDEX globalhashindex1 ON mytab(a) INCLUDE (b,c) PAGES=200 DISTRIBUTE BY HASH (a); Command> indexes MYTAB; Indexes on table SAMPLEUSER.MYTAB: MYTAB: unique range index on columns: C B GLOBALHASHINDEX1: global non-unique hash index on columns: A Included columns: B C 2 indexes found. 2 indexes found on 1 table.
See "Examples: TimesTen Scaleout" for additional examples.
General description of indexes in TimesTen Scaleout
-
TimesTen creates a nonunique range index by default. Specify
CREATEUNIQUE INDEXto create a unique range index. -
To create a nonunique hash index, specify
CREATEHASHINDEX. To create a unique hash index, specifyCREATEUNIQUEHASHINDEX. -
If
UNIQUEis specified, all existing rows must have unique values in the indexed column(s). -
The new index is maintained automatically until the index is deleted by a
DROP INDEXstatement or until the table associated with it is dropped. -
Any prepared statements that reference the table with the new index are automatically prepared again the next time they are executed. Then the statements can take advantage, if possible, of the new index.
-
An index on a temporary table cannot be created by a connection if any other connection has a non-empty instance of the table.
-
If you are using linguistic comparisons, you can create a linguistic index. A linguistic index uses sort key values and storage is required for these values. Only one unique value for
NLS_SORTis allowed for an index. For more information on linguistic indexes and linguistic comparisons, see "Using linguistic indexes" in Oracle TimesTen In-Memory Database Operations Guide. -
If you create indexes that are redundant, TimesTen generates warnings or errors. Call
ttRedundantIndexCheckto see the list of redundant indexes for your tables. -
To change the size or type of a hash index, drop the hash index and create a new index.
-
A hash index is created with a fixed size that remains constant for the life of the table. To resize the hash index, drop and recreate the index. If the hash index has insufficient pages it results in hash collisions which slows down the index look-up. Hash key comparison is a fast operation, so a small number of hash collisions should not cause a performance problem for TimesTen.
To ensure that your hash index is sized correctly, your application must indicate the expected size of your table with the value of the
RowPagesparameter of theSETPAGESclause. Compute this value by dividing the number of expected rows in your table by 256. For example, if your table has 256,000 rows, specify 1000 for the value of RowPages (256000/256=1000). -
The maximum number of columns that can be specified for an index is 32.
Using indexes in query processing
Proper indexes can improve query performance. Some queries can benefit from the use of indexes and some queries do not benefit from the use of indexes. Additionally, the choice of indexes for your queries is important.
A range index is ideal for processing range searches and exact matches, especially if most of the values in the index columns are unique. For example, if a range index is defined on columns (C1,C2), the index can be used to process the following types of predicates. ConstantOrParam refers to a constant value or dynamic parameter and range refers to the operators >,<,>=, or <=:
-
C1=ConstantOrParamANDC2=ConstantOrParam -
C1=ConstantOrParamANDC2rangeConstantOrParam -
C1=ConstantOrParam -
C1rangeConstantOrParam
A range index efficiently processes equality and range predicates and efficiently processes sort and group operations. Use range indexes on index columns with many unique values. The order of columns you specify in a range index is relevant. The order of expressions in the predicate of a query that uses the range index is not relevant. When your query is processed, only one range index is used for each scan of your table even if you have defined multiple range indexes on your table.
A hash index efficiently processes equality predicates. You must size your hash index correctly for optimal performance. Use the PAGES parameter to size your hash index. If you specify a PAGES value that is too small, a large number of hash collisions may result, leading to performance degradation for statements that access the hash index. The order of columns specified in the hash index is not relevant and the order of expressions in the predicate of the query that uses the hash index is not relevant. If either a hash index or a range index can be used to process a particular equality predicate, the hash index is chosen because a lookup in a hash index is faster than a scan of a range index.
You can influence the indexes used by the optimizer by setting statement level or transaction level optimizer hints. see "Statement level optimizer hints" for information on statement level optimizer hints. For more information on transaction level optimizer hints, see "ttOptSetFlag", ttOptSetOrder", or "ttOptUseIndex" in the Oracle TimesTen In-Memory Database Reference.
Examples: TimesTen Scaleout
These examples illustrate the syntax requirements for creating a global index. You must specify the GLOBAL keyword to create a global index.
Illustrate global index syntax
This example illustrates the supported syntax for a global index.
Create a table with three columns (c,b,a) and define a primary key on two of those columns (c,b). Distribute the table by hash on columns (a,b).
(c,b). Command> CREATE TABLE mytab1 (c TT_INTEGER NOT NULL, b TT_INTEGER NOT NULL, a TT_INTEGER NOT NULL,
PRIMARY KEY (c,b)) DISTRIBUTE BY HASH (a,b);
Command> CREATE GLOBAL UNIQUE INDEX mygix1 ON mytab1 (c,b);
Command> indexes mytab1;
Indexes on table SAMPLEUSER.MYTAB1:
MYGIX1: global unique range index on columns:
C
B
MYTAB1: unique range index on columns:
C
B
2 indexes found.
2 indexes found on 1 table.
INCLUDE clause.
Command> CREATE GLOBAL INDEX mygix2 ON MYTAB1(b) include (a);
Command> indexes mytab1
Indexes on table SAMPLEUSER.MYTAB1:
MYGIX1: global unique range index on columns:
C
B
MYTAB1: unique range index on columns:
C
B
MYGIX2: global non-unique range index on columns:
B
Included columns:
A
3 indexes found.
3 indexes found on 1 table.b. Command> DROP INDEX mygix2;
Command> CREATE GLOBAL INDEX mygix2 ON MYTAB1(b) INCLUDE (a) DISTRIBUTE BY HASH(b);
Command> INDEXES mytab1
Indexes on table SAMPLEUSER.MYTAB1:
MYGIX1: global unique range index on columns:
C
B
MYTAB1: unique range index on columns:
C
B
MYGIX2: global non-unique range index on columns:
B
Included columns:
A
3 indexes found.
3 indexes found on 1 table.
Create a global hash index.
Command> CREATE GLOBAL HASH INDEX mygix3 ON mytab1(a) PAGES =200;
Command> indexes mytab1;
Indexes on table SAMPLEUSER.MYTAB1:
MYGIX1: global unique range index on columns:
C
B
MYTAB1: unique range index on columns:
C
B
MYGIX3: global non-unique hash index on columns:
A
MYGIX2: global non-unique range index on columns:
B
Included columns:
A
4 indexes found.
4 indexes found on 1 table.
Distribution key of global index is same as distribution key of table
This example illustrates that you cannot create a global index whose distribution key is the same as the distribution key of the table. In this example, the mytab1 table is distributed by hash on columns (a,b). An attempt to create a global index, with columns (a,b) as the distribution key, results in an error.
Command> CREATE TABLE mytab1 (a TT_INTEGER NOT NULL, b TT_INTEGER NOT NULL,
c TT_INTEGER NOT NULL) DISTRIBUTE BY HASH (a,b);
Command> CREATE GLOBAL INDEX gix1 ON mytab1(a,b,c) DISTRIBUTE BY HASH (a,b);
2253: Distribution key for global index cannot be same as that of the table or
other global index. Consider creating a local index.
The command failed.
Global index creates its own materialized view and its own local index
This example illustrates that when you create a global index, TimesTen Scaleout creates its own internal materialized view and its own local index. Create the mytab2 table distributed by hash on columns (a,b). Create a global non-unique range index distributed by hash on columns (b,a). Run the ttIsql indexes command to show the gix2 global index is created as well as an internal local index on the internal materialized view. Then, run the ttIsql views command to show an internal materialized view is also created as a result of creating the global index. Run the ttIsql describe command to show the internal materialized view. Note that you cannot explicitly drop the internal materialized view or the internal local index.
Command> CREATE TABLE mytab2 (a TT_INTEGER NOT NULL, b TT_INTEGER NOT NULL,
c TT_INTEGER NOT NULL) DISTRIBUTE BY HASH (a,b);
Command> CREATE GLOBAL INDEX gix2 ON mytab2(a,b,c) DISTRIBUTE BY HASH (b,a);
Command> indexes;
Indexes on materialized view SAMPLEUSER.$GV9B55D3955D52:
$GVI9B55D3955D52: non-unique range index on columns:
A
B
C
1 index found.
Indexes on table SAMPLEUSER.MYTAB2:
GIX2: global non-unique range index on columns:
A
B
C
1 index found.
2 indexes found on 2 tables.
Command> views;
SAMPLEUSER.$GV9B55D3955D52
1 view found.
Command> describe SAMPLEUSER.$GV9B55D3955D52;
Materialized view SAMPLEUSER.$GV9B55D3955D52:
Global index: GIX2 (table: MYTAB2)
Columns:
A TT_INTEGER NOT NULL
B TT_INTEGER NOT NULL
C TT_INTEGER NOT NULL
DISTRIBUTE BY HASH (B, A)
1 view found.
Examples: TimesTen Classic
Create a table and then create a unique hash index on col2. Do not specify the PAGES clause. If PAGES is not specified, the current table page count is used for the size of the hash table. Use INDEXES to verify the index was created. Insert a row in the table, set SHOWPLAN to 1 and then verify the optimizer uses the hash index.
Command> CREATE TABLE tab (col1 NUMBER PRIMARY KEY NOT NULL, col2 VARCHAR2 (30));
Command> CREATE UNIQUE HASH INDEX hash1 ON tab (col2);
Command> INDEXES;
Indexes on table TESTUSER.TAB:
HASH1: unique hash index on columns:
COL2
TAB: unique range index on columns:
COL1
2 indexes found.
2 indexes found on 1 table.
Command> INSERT INTO tab VALUES (10, 'ABC');
Command> SHOWPLAN 1;
Command> SELECT * FROM tab where col2 = 'ABC';
Query Optimizer Plan:
STEP: 1
LEVEL: 1
OPERATION: RowLkHashScan
TBLNAME: TAB
IXNAME: HASH1
INDEXED CONDITION: TAB.COL2 = 'ABC'
NOT INDEXED: <NULL>
< 10, ABC >
1 row found.
Create a table and create a nonunique hash index on col1. Use PAGES = CURRENT to use the current table page count to size the hash index. Use INDEXES to verify the nonunique hash index is created.
Command> CREATE TABLE tab2 (col1 NUMBER);
Command> CREATE HASH INDEX hash_index ON tab2 (col1) PAGES = CURRENT;
Command> INDEXES;
Indexes on table TESTUSER.TAB2:
HASH_INDEX: non-unique hash index on columns:
COL1
1 index found.
1 index found on 1 table.
Create table and create unique hash index on col3. Use PAGES = 100 to specify a page count of 100 for the size of the hash table. Use INDEXES to verify the unique hash index is created.
Command> CREATE TABLE tab3 (col1 NUMBER, col2 NUMBER, col3 TT_INTEGER);
Command> CREATE UNIQUE HASH INDEX unique_hash1 on tab3 (col3) PAGES = 100;
Command> INDEXES;
Indexes on table TESTUSER.TAB3:
UNIQUE_HASH1: unique hash index on columns:
COL3
1 index found.
1 index found on 1 table.
The regions table in the HR schema creates a unique index on region_id. Issue the ttIsql INDEXES command on table regions. You see the unique range index regions.
Command> INDEXES REGIONS;
Indexes on table SAMPLEUSER.REGIONS:
REGIONS: unique range index on columns:
REGION_ID
(referenced by foreign key index COUNTR_REG_FK on table SAMPLEUSER.COUNTRIES)
1 index found.
1 index found on 1 table.
Attempt to create a unique index i on table regions indexing on column region_id. You see a warning message.
Command> CREATE UNIQUE INDEX i ON regions (region_id); Warning 2232: New index I is identical to existing index REGIONS; consider dropping index I
Call ttRedundantIndexCheck to see warning message for this index:
Command> CALL ttRedundantIndexCheck ('regions');
< Index SAMPLEUSER.REGIONS.I is identical to index SAMPLEUSER.REGIONS.REGIONS;
consider dropping index SAMPLEUSER.REGIONS.I >
1 row found.
Create table redundancy and define columns co11 and col2. Create two user indexes on col1 and col2. You see an error message when you attempt to create the second index r2. Index r1 is created. Index r2 is not created.
Command> CREATE TABLE redundancy (col1 CHAR (30), col2 VARCHAR2 (30)); Command> CREATE INDEX r1 ON redundancy (col1, col2); Command> CREATE INDEX r2 ON redundancy (col1, col2); 2231: New index R2 would be identical to existing index R1 The command failed.
Issue the ttIsql command INDEXES on table redundancy to show that only index r1 is created:
Command> INDEXES redundancy;
Indexes on table SAMPLEUSER.REDUNDANCY:
R1: non-unique range index on columns:
COL1
COL2
1 index found.
1 index found on 1 table.
This unique index ensures that all part numbers are unique.
CREATE UNIQUE INDEX purchasing.partnumindex ON purchasing.parts (partnumber);
Create a linguistic index named german_index on table employees1. To have more than one linguistic sort, create a second linguistic index.
Command> CREATE TABLE employees1 (id CHARACTER (21), id2 character (21)); Command> CREATE INDEX german_index ON employees1 (NLSSORT(id, 'NLS_SORT=GERMAN')); Command> CREATE INDEX german_index2 ON employees1 (NLSSORT(id2, 'nls_sort=german_ci')); Command> indexes employees1; Indexes on table SAMPLEUSER.EMPLOYEES1: GERMAN_INDEX: non-unique range index on columns: NLSSORT(ID,'NLS_SORT=GERMAN') GERMAN_INDEX2: non-unique range index on columns: NLSSORT(ID2,'nls_sort=german_ci') 2 indexes found. 1 table found.
See also
CREATE MATERIALIZED VIEW
The CREATE MATERIALIZED VIEW statement creates a view of the table specified in the SelectQuery clause. The original tables used to create a view are referred to as detail tables. The view is refreshed synchronously with regard to changes in the detail tables.
Required privileges
User executing the statement must have CREATE MATERIALIZED VIEW (if owner) or CREATE ANY MATERIALIZED VIEW (if not owner) privilege.
SELECTprivilege on the detail tables.CREATETABLEprivilege.
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout. You must specify the DISTRIBUTE BY HASH clause and you must define a distribution key. The DISTRIBUTE BY REFERENCE and DUPLICATE clauses are not supported.
SQL syntax: TimesTen Scaleout
CREATE MATERIALIZED VIEW [Owner.]ViewNameDISTRIBUTE BY HASH (ColumnName[,...]) ASSelectQuery[PRIMARY KEY (ColumnName[,...])] [UNIQUE HASH ON (HashColumnName[,...]) PAGES =PrimaryPages]
SQL syntax: TimesTen Classic
CREATE MATERIALIZED VIEW [Owner.]ViewNameASSelectQuery[PRIMARY KEY (ColumnName[,...])] [UNIQUE HASH ON (HashColumnName [,...]) PAGES =PrimaryPages]
Parameters
| Parameter | Description |
|---|---|
|
|
Name assigned to the new view. |
|
|
TimesTen Scaleout only. You must specify the The detail table must be distributed by hash.
This clause must appear before the |
|
|
Select column from the detail tables to be used in the view. |
|
|
Name of the column(s) that forms the primary key for the view to be created. Up to 32 columns can be specified for the primary key. Each result column name of a viewed table must be unique. The column name definition cannot contain the table or owner component. |
|
|
Hash index for the table. Only unique hash indexes are created. This parameter is used for equality predicates. |
|
|
Column defined in the view that is to participate in the hash key of this table. The columns specified in the hash index must be identical to the columns in the primary key. |
|
|
Sizes the hash index to reflect the expected number of pages in your table. To determine the value for The value for If your estimate for See "CREATE TABLE" for information on hash indexes. |
Description and restrictions for CREATE MATERIALIZED VIEW: TimesTen Scaleout
Description and restrictions include:
-
The SQL optimizer may re-write a query against a base table to use an available materialized view if the use of the materialized view is expected to improve the execution time of the query.
-
You must specify the
DISTRIBUTEBYHASHclause and you must specify it with a distribution key (even if you have specified a primary key and intend to use the primary key as the distribution key). -
You must specify the
DISTRIBUTEBYHASHclause before theASSelectQueryclause. -
You can only specify the
DISTRIBUTEBYHASHclause. TheDISTRIBUTEBYREFERENCEandDUPLICATEclauses are not supported. -
The
SelectQuerymust be restricted to single tableSELECTstatements. -
You cannot specify the
GROUPBYor theWHEREclause in theSelectQuery. -
You cannot use SQL functions in the
SelectQuery. -
You cannot use an expression in the
SelectQuery. -
The detail table of the materialized view cannot have a foreign key with a cascade delete clause.
-
The distribution key columns must be in the project list of the
SelectQuery. -
There are no DDL rewrites. For example, if you create a unique index on the detail table, a corresponding index on the materialized view (which is distributed on the unique column) is not created.
Description: TimesTen Scaleout and TimesTen Classic
The restrictions and requirements on the defining query include:
-
Each expression in the select list must have a unique name.
-
Do not use non-materialized views to define a materialized view.
-
Do not define
CLOB,BLOB, orNCLOBdata types for columns in the select list of the materialized view query. -
The detail tables cannot belong to a cache group and the detail tables cannot have compression.
-
Do not use
SELECTFORUPDATE. -
Do not reference system tables or views.
-
Do not use nested definitions for a materialized view.
-
Do not use dynamic parameters.
-
Do not use
ROWNUM. -
Do not use analytic functions.
-
Do not use
GROUPINGSETS,ROLLUP, orCUBE. -
Do not use the
SYSDATEfunction. -
Do not use the functions
SYSTEM_USER,USER,CURRENT_USER, orSESSION_USER. -
Do not use
NEXTVALorCURRVAL. -
Outer joins are allowed but the select list must project at least one non-nullable column from each of the inner tables specified in the outer join.
-
Do not use the
WITHsubqueryclause.
The restrictions (not on the defining query) include:
-
Do not have a hash-based primary key that contains any aggregate columns of the materialized view.
-
A materialized view cannot be replicated directly using TimesTen replication. You can replicate the detail tables. You must define the same materialized view on both sides of replication. TimesTen automatically updates the corresponding materialized views.
-
You cannot define a foreign key if the referencing or referenced table is a materialized view.
The following restrictions and requirements on the defining query are:
-
The view definition must include all columns in the group by list in the select list.
-
An aggregate view must include a
COUNT (*)orCOUNT(non-nullable column) in the select list. -
Do not use derived tables or
JOINtables. -
Do not use
SELECTDISTINCTor an aggregate distinct function. -
Do not use the set operators
UNION,MINUS, orINTERSECT. -
Do not use
SUMof nullable expressions. -
Use only simple columns as group by columns.
-
Group by columns cannot belong to self join tables.
-
Do not use these clauses:
-
HAVING -
ORDERBY -
DISTINCT -
FIRST -
JOIN
-
-
Do not use the
TT_HASHfunction. -
You can use
SUMandCOUNTbut do not use expressions involvingSUMandCOUNT. Do not useAVG, which is treated asSUM/COUNT. -
Do not specify
MINorMAXfunctions in the select list. -
For joins:
-
Join predicates cannot have an
OR. -
Do not specify Cartesian product joins (joins with no join predicate).
-
For outer joins, outer join each inner table with at most one table.
-
Additional considerations include:
-
A materialized view is read-only and cannot be updated directly. A materialized view is updated only when changes are made to the associated detail tables. Therefore a materialized view cannot be the target of a
DELETE,UPDATEorINSERTstatement. -
By default, a range index is created to enforce the primary key for a materialized view. Alternatively, use the
UNIQUE HASHclause to specify a hash index for the primary key.-
If your application performs range queries over a materialized view's primary key, then choose a range index for that view by omitting the
UNIQUE HASHclause. -
If your application performs only exact match lookups on the primary key, then a hash index may offer better response time and throughput. In such a case, specify the
UNIQUE HASHclause. See "CREATE TABLE" for more information about theUNIQUE HASHclause.
-
-
You can use
ALTER TABLEto change the representation of the primary key index or resize a hash index of a materialized view. -
You cannot add or drop columns in the materialized view with the
ALTER TABLEstatement. To change the structure of the materialized view, drop and recreate the view. -
You can create indexes on the materialized view with the
CREATE INDEXSQL statement.
The owner of a materialized view must have the SELECT privilege on its detail tables. The SELECT privilege is implied by the SELECT ANY TABLE and ADMIN system privileges. When the SELECT privilege or a higher-level system privilege on the detail tables is revoked from the owner of the materialized view, the materialized view becomes invalid.
Selecting from an invalid materialized view fails with an error. Updates to the detail tables of an invalid materialized view do not update the materialized view.
You can identify invalid materialized views by using the ttIsql describe command and by inspecting the STATUS column of the SYS.DBA_OBJECTS, SYS.ALL_OBJECTS or SYS.USER_OBJECTS system tables. See Oracle TimesTen In-Memory Database System Tables and Views
Reference.
If the revoked privilege is restored, you can make an invalid materialized view valid again by dropping and recreating the materialized view.
For more information, see "Object privileges for materialized views" in Oracle TimesTen In-Memory Database Security Guide.
Examples for CREATE MATERIALIZED VIEW: TimesTen Scaleout
Syntax example:
Command> CREATE MATERIALIZED VIEW mv
DISTRIBUTE BY HASH (phone)
AS SELECT phone FROM accounts;
1010 rows materialized.
Examples: TimesTen Classic
Create a materialized view of columns from the customer and bookorder tables.
CREATE MATERIALIZED VIEW custorder AS SELECT custno, custname, ordno, book FROM customer, bookorder WHERE customer.custno=bookorder.custno;
Create a materialized view of columns x1 and y1 from the t1 table.
CREATE MATERIALIZED VIEW v1 AS SELECT x1, y1 FROM t1 PRIMARY KEY (x1) UNIQUE HASH ON (x1) PAGES=100;
Create a materialized view from an outer join of columns x1 and y1 from the t1 and t2 tables.
CREATE MATERIALIZED VIEW v2 AS SELECT x1, y1 FROM t1, t2 WHERE x1=x2(+);
The following example creates a materialized view empmatview2 based on selected columns employee_id and email from table employees. After the materialized view is created, create an index on the materialized view column mvemp_id of the materialized view empmatview2.
CREATE MATERIALIZED VIEW empmatview2
AS SELECT employee_id mvemp_id, email mvemail
FROM employees;
107 rows materialized.
CREATE INDEX empmvindex ON empmatview2 (mvemp_id);CREATE PACKAGE
The CREATE PACKAGE statement creates the specification for a standalone package, which is an encapsulated collection of related procedures, functions, and other program objects stored together in your database. The package specification declares these objects. The package body defines these objects.
Required privilege
CREATE PROCEDURE (if owner) or CREATE ANY PROCEDURE (if not owner).
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
CREATE [OR REPLACE] PACKAGE [Owner.]PackageName
[InvokerRightsClause] [AccessibleByClause]
{IS|AS}
PlsqlPackageSpec
InvokerRightsClause::=
AUTHID {CURRENT_USER | DEFINER}
AccessibleByClause::=
ACCESSIBLE BY (accessor[,...])
accessor::=
[UnitKind][Owner.]UnitName
You can specify InvokerRightsClause or AccessibleByClause in any order.
Parameters
| Parameter | Description |
|---|---|
|
|
Specify |
|
|
Name of the package. |
|
|
Lets you specify whether the SQL statements in PL/SQL functions or procedures execute with definer's or invoker's rights. The
For more information, see "Definer's rights and invoker's rights (AUTHID clause)" in the Oracle TimesTen In-Memory Database Security Guide. |
|
|
Use this clause to specify one or more accessors (PL/SQL units) that can invoke the package directly. The list of accessors that can access the package is called a white list. A white list gives you the ability to add an extra layer of security to your PL/SQL objects. Specifically, you can restrict access to the package to only those objects on the white list.
Syntax: |
|
|
Used in An accessor can appear more than once in the Syntax: |
|
|
Used in the
|
|
|
Used in the You can optionally specify |
|
|
Specify either |
|
|
Specifies the package specification. Can include type definitions, cursor declarations, variable declarations, constant declarations, exception declarations and PL/SQL subprogram declarations. |
Description
-
AccessibleByClause:-
AccessibleByClauseis valid at the top-level package definition. You cannot specifyAccessibleByClausein the individual procedures or functions within the package. In addition, you cannot specifyAccessibleByClausein theCREATEPACKAGEBODYstatement. -
You can use this clause to restrict access to helper packages. For example, assume your PL/SQL package defines an API for a given functionality and that functionality is implemented using a set of helper procedures and functions. You want to limit applications to only be able to call the API procedure or function that is defined in your package, and to not be able to call the helper procedures and functions directly. You can use the
ACCESSIBLEBYclause to achieve this. -
The compiler checks the validity of the syntax of the
ACCESSIBLEBYclause, but does not check that the accessor exists. Therefore, you can define an accessor that does yet exist in the owner's schema. -
When you invoke the package, the compiler first does the normal permission checks on the invocation. If any check fails, the invocation fails, even if the invoker is an accessor. If all normal permission checks on the invocation succeed, and the package has no
ACCESSIBLEBYclause, the invocation succeeds. If the package has anACCESSIBLEBYclause, the invocation succeeds only if the invoker is an accessor.
-
-
When you create or replace a package, the privileges granted on the package remain the same. If you drop and recreate the object, the object privileges that were granted on the original object are revoked.
-
In a replicated environment, the
CREATE PACKAGEstatement is not replicated. For more information, see "Creating a new PL/SQL object in an existing active standby pair" and "Adding a PL/SQL object to an existing classic replication scheme" in the Oracle TimesTen In-Memory Database Replication Guide.
Examples
Illustrating the correct usage of the AccessibleByClause
This example illustrates the correct usage of the AccessibleByClause. The clause is specified at the top-level of the CREATE PACKAGE statement. Note that the CallingProc procedure does not need to exist.
Command> CREATE OR REPLACE PACKAGE ProtectedPkg
ACCESSIBLE BY (PROCEDURE CallingProc)
AS
PROCEDURE ProtectedProc;
END;
/
Package created.Illustrating the incorrect usage of the AccessibleByClause
These examples show the incorrect use of the AccessibleByClause. The first example attempts to use AccessibleByClause in the packaged procedure, resulting in a compilation error. The second example attempts to use AccessibleByClause in the CREATE PACKAGE BODY statement, resulting in a compilation error.
This example uses the ACCESSIBLE BY clause in the packaged procedure.
Command> CREATE OR REPLACE PACKAGE ProtectedPkg1
AS
PROCEDURE ProtectedProc1
ACCESSIBLE BY (PROCEDURE CallingProc)
END;
/
Warning: Package created with compilation errors.
Command> SHOW ERRORS
Errors for PACKAGE PROTECTEDPKG1:
LINE/COL ERROR
-------- -----------------------------------------------------------------
0/0 PLS-00157: Only schema-level programs allow ACCESSIBLE BY
This example uses the ACCESSIBLE BY clause in the CREATE PACKAGE BODY statement.
Command> CREATE OR REPLACE PACKAGE ProtectedPkg3
ACCESSIBLE BY (PROCEDURE CallingProc3)
AS
PROCEDURE ProtectedProc3;
END;
/
Package created.
Command> CREATE OR REPLACE PACKAGE BODY ProtectedPkg3
ACCESSIBLE BY (PROCEDURE CallingProc3)
AS
PROCEDURE ProtectedProc3 AS
BEGIN
NULL;
END;
;
/
Warning: Package body created with compilation errors.
Command> SHOW ERRORS
Errors for PACKAGE BODY PROTECTEDPKG3:
LINE/COL ERROR
-------- -----------------------------------------------------------------
2/1 PLS-00103: Encountered the symbol "ACCESSIBLE" when expecting one of the
following:
is as compress compiled wrappedEnsuring only the API can access the helper package
This example walks through a series of steps to illustrate the use of the AccessibleByClause. The example creates the SampleAPI package and the SampleHelper package. The ACCESSIBLE BY clause is specified on the SampleHelper to ensure that only the SampleAPI package can access the SampleHelper package.
Steps:
-
Create the
SampleHelperpackage. Specify theACCESSIBLEBYclause, giving theSampleAPIpackage access to theSampleHelperpackage. TheSampleAPIpackage is in the white list.Command> CREATE OR REPLACE PACKAGE SampleHelper ACCESSIBLE BY (SampleAPI) AS PROCEDURE SampleH1; PROCEDURE SampleH2; END; / Package created. -
Create the
SampleHelperpackage body.Command> CREATE OR REPLACE PACKAGE BODY SampleHelper AS PROCEDURE SampleH1 AS BEGIN DBMS_OUTPUT.PUT_LINE('Sample helper procedure SampleH1'); END; PROCEDURE SampleH2 AS BEGIN DBMS_OUTPUT.PUT_LINE('Sample helper procedure SampleH2'); END; END; / Package body created. -
Create the
SampleAPIpackage.Command> CREATE OR REPLACE PACKAGE SampleAPI AS PROCEDURE p1; PROCEDURE p2; END; / Package created. -
Create the
SampleAPIpackage body. Thep1procedure references theSampleHelper.SampleH1procedure. Thep2procedure references theSampleHelper.SampleH2procedure.Command> CREATE OR REPLACE PACKAGE BODY SampleAPI AS PROCEDURE p1 AS BEGIN DBMS_OUTPUT.PUT_LINE('SampleAPI procedure p1'); SampleHelper.SampleH1; END; PROCEDURE p2 AS BEGIN DBMS_OUTPUT.PUT_LINE('SampleAPI procedure p2'); SampleHelper.SampleH2; END; END; / Package body created. -
Call the
SampleAPI.p1and theSampleAPI.p2procedures. TheSampleAPIpackage is in the white list of theSampleHelperpackage, resulting in successful execution.Command> SET SERVEROUTPUT ON Command> BEGIN SampleAPI.p1; SampleAPI.p2; END; / SampleAPI procedure p1 Sample helper procedure SampleH1 SampleAPI procedure p2 Sample helper procedure SampleH2 PL/SQL procedure successfully completed. -
Call the
SampleHelper.SampleH1procedure directly. An error is returned due to insufficient access privileges.Command> BEGIN SampleHelper.SampleH1; END; / 8503: ORA-06550: line 2, column 3: PLS-00904: insufficient privilege to access object SAMPLEHELPER 8503: ORA-06550: line 2, column 3: PL/SQL: Statement ignored The command failed.
CREATE PACKAGE BODY
The CREATE PACKAGE BODY statement creates the body of a standalone package. A package is an encapsulated collection of related procedures, functions, and other program objects stored together in your database. A package specification declares these objects. A package body defines these objects.
Required privilege
CREATE PROCEDURE (if owner) or CREATE ANY PROCEDURE (if not owner).
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
CREATE [OR REPLACE] PACKAGE BODY [Owner.]PackageBody {IS|AS} plsql_package_body
Parameters
| Parameter | Description |
|---|---|
|
|
Specify |
|
|
Name of the package body. |
|
|
Specify either |
|
|
Specifies the package body which consists of PL/SQL subprograms. |
Description
In a replicated environment, the CREATE PACKAGE BODY statement is not replicated. For more information, see "Creating a new PL/SQL object in an existing active standby pair" and "Adding a PL/SQL object to an existing classic replication scheme" in the Oracle TimesTen In-Memory Database Replication Guide.
When you create or replace a package body, the privileges granted on the package body remain the same. If you drop and recreate the object, the object privileges that were granted on the original object are revoked.
CREATE PROCEDURE
The CREATE PROCEDURE statement creates a standalone stored procedure.
Required privilege
CREATE PROCEDURE (if owner) or CREATE ANY PROCEDURE (if not owner).
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
CREATE [OR REPLACE] PROCEDURE [Owner.]ProcedureName[(arguments [IN|OUT|IN OUT][NOCOPY] DataType [DEFAULT expr][,...])] [InvokerRightsClause][AccessibleByClause] [DETERMINISTIC] {IS|AS} plsql_procedure_body InvokerRightsClause::= AUTHID {CURRENT_USER|DEFINER} AccessibleByClause::= ACCESSIBLE BY(accessor[,...])accessor::= [UnitKind][Owner.]UnitName
You can specify InvokerRightsClause, AccessibleByClause, or DETERMINISTIC in any order.
Parameters
| Parameter | Description |
|---|---|
|
|
Specify |
|
|
Name of procedure. |
|
|
Name of argument/parameter. You can specify 0 or more parameters for the procedure. If you specify a parameter, you must specify a data type for the parameter. The data type must be a PL/SQL data type. |
|
|
Parameter modes.
|
|
|
Specify |
|
|
Use this clause to specify a |
|
|
Lets you specify whether the SQL statements in PL/SQL functions or procedures execute with definer's or invoker's rights. The
For more information, see "Definer's rights and invoker's rights (AUTHID clause)" in the Oracle TimesTen In-Memory Database Security Guide. |
|
|
Use this clause to specify one or more accessors (PL/SQL units) that can invoke the procedure directly. The list of accessors that can access the procedure is called a white list. A white list gives you the ability to add an extra layer of security to your PL/SQL objects. Specifically, you can restrict access to the procedure to only those objects on the white list. The Syntax: |
|
|
Used in the An accessor can appear more than once in the Syntax: |
|
|
Used in the
|
|
|
Used in the You can optionally specify |
|
|
Specify |
|
|
Specify either |
|
|
Specifies the procedure body. |
Description
-
AccessibleByClause:-
The compiler checks the validity of the syntax of the
AccessibleByClause, but does not check that the accessor exists. Therefore, you can define an accessor that does yet exist in the owner's schema. -
When you invoke the procedure, the compiler first does the normal permission checks on the invocation. If any check fails, the invocation fails, even if the invoker is an accessor. If all normal permission checks on the invocation succeed, and the procedure has no
AccessibleByClause, the invocation succeeds. If the procedure has anAccessibleByClause, the invocation succeeds only if the invoker is an accessor.
-
-
When you create or replace a procedure, the privileges granted on the procedure remain the same. If you drop and recreate the object, the object privileges that were granted on the original object are revoked.
-
The namespace for PL/SQL procedures is distinct from the TimesTen built-in procedures. You can create a PL/SQL procedure with the same name as a TimesTen built-in procedure.
-
TimesTen does not support:
-
call_specclause -
AS EXTERNALclause
-
-
In a replicated environment, the
CREATE PROCEDUREstatement is not replicated. For more information, see "Creating a new PL/SQL object in an existing active standby pair" and "Adding a PL/SQL object to an existing classic replication scheme" in the Oracle TimesTen In-Memory Database Replication Guide.
Examples
Using the AccessibleByClause
This example creates the ProtectedProc procedure and uses the ACCESSIBLE BY clause to restrict access to the CallingProc procedure. The CallingProc procedure does not yet exist. The example then creates the CallingProc procedure, which calls the ProtectedProc procedure. The CallingProc procedure is successfully created, as it is specified in the ACCESSIBLE BY clause. The example then attempts to call the ProtectedProc procedure directly, resulting in an error. It concludes with attempting to create the AnotherCallingProc procedure that references the ProtectedProc procedure, but the AnotherCallingProc procedure is not in the white list. A compilation error results.
Steps to illustrate the example:
-
Create the
ProtectedProcprocedure, specifying theACCESSIBLEBYclause. TheCallingProcprocedure is in the white list. It does not yet exist.Command> CREATE OR REPLACE PROCEDURE ProtectedProc ACCESSIBLE BY (CallingProc) AS BEGIN DBMS_OUTPUT.PUT_LINE ('ProtectedProc'); END; / Procedure created. -
Create the
CallingProcprocedure, referencing theProtectedProcprocedure.Command> CREATE OR REPLACE PROCEDURE CallingProc AS BEGIN DBMS_OUTPUT.PUT_LINE ('CallingProc'); ProtectedProc; END; / Procedure created. -
Call the
CallingProcprocedure. The procedure is successfully executed.Command> SET SERVEROUTPUT ON Command> exec CallingProc; CallingProc ProtectedProc PL/SQL procedure successfully completed.
-
Attempt to call the
ProtectedProcprocedure directly. An error is thrown due to insufficient access privileges.Command> exec ProtectedProc; 8503: ORA-06550: line 1, column 7: PLS-00904: insufficient privilege to access object PROTECTEDPROC 8503: ORA-06550: line 1, column 7: PL/SQL: Statement ignored The command failed.
-
Create the
AnotherCallingProcprocedure that references theProtectedProcprocedure. TheAnotherCallingProcis not in the white list (not listed in theACCESSIBLEBYclause ofProtectedProc), resulting in a compilation error.Command> CREATE OR REPLACE PROCEDURE AnotherCallingProc AS BEGIN DBMS_OUTPUT.PUT_LINE ('AnotherCallingProc'); ProtectedProc; END; / Warning: Procedure created with compilation errors. Command> SHOW ERRORS Errors for PROCEDURE ANOTHERCALLINGPROC: LINE/COL ERROR -------- ----------------------------------------------------------------- 5/1 PL/SQL: Statement ignored 5/1 PLS-00904: insufficient privilege to access object PROTECTEDPROC
Using the accessor clause
This example illustrates the uses of the accessor clause through a sequence of steps.
-
Create the
SampleUser1andSampleUser2users and grantADMINprivileges to both users.Command> CREATE USER SampleUser1 IDENTIFIED BY SampleUser1; User created. Command> CREATE USER SampleUser2 IDENTIFIED BY SampleUser2; User created. Command> GRANT ADMIN TO SampleUser1, SampleUser2;
-
Create the
SampleUser1.ProtectedProcprocedure, specifying theACCESSIBLEBYclause. TheCallingProcprocedure is specified in the white list without an owner. The owner of theCallingProcprocedure is assumed to be in the same schema as the owner of the procedure with theACCESSIBLEBYclause. Thus,CallingProcis assumed to be in theSampleUser1schema.Command> CREATE OR REPLACE PROCEDURE SampleUser1.ProtectedProc ACCESSIBLE BY (CallingProc) AS BEGIN DBMS_OUTPUT.PUT_LINE ('SampleUser1 ProtectedProc'); END; / Procedure created. -
Connect as
SampleUser1. Create theCallingProcprocedure, referencing theSampleUser1.ProtectedProcprocedure.Command> Connect adding "uid=SampleUser1;pwd=SampleUser1PW" as SampleUser1; Connection successful: DSN=database1;UID=SampleUser1;DataStore=/scratch/sampleuser1/database1; DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=AL32UTF8; PermSize=128; (Default setting AutoCommit=1) sampleuser1: Command> CREATE OR REPLACE PROCEDURE CallingProc AS BEGIN DBMS_OUTPUT.PUT_LINE ('SampleUser1 CallingProc'); ProtectedProc; END; / Procedure created. -
From the
SampleUser1connection, call theCallingProcprocedure. The call succeeds.sampleuser1: Command> SET SERVEROUTPUT ON sampleuser1: Command> exec CallingProc; SampleUser1 CallingProc SampleUser1 ProtectedProc PL/SQL procedure successfully completed.
-
Connect to
SampleUser2. Create theCallingProcprocedure, referencing theSampleUser1.ProtectedProcprocedure. A compilation error results.SampleUser1: Command> connect adding "uid=Sampleuser2;pwd=SampleUser2PW" as SampleUser2; Connection successful: DSN=database1;UID=Sampleuser2;DataStore=/scratch/sampleuser2/database1; DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=AL32UTF8; PermSize=128; (Default setting AutoCommit=1) sampleuser2: Command> CREATE OR REPLACE PROCEDURE CallingProc AS BEGIN DBMS_OUTPUT.PUT_LINE ('SampleUser2 CallingProc'); SampleUser1.ProtectedProc; END; / Warning: Procedure created with compilation errors. sampleuser2: Command> SHOW ERRORS Errors for PROCEDURE CALLINGPROC: LINE/COL ERROR -------- ----------------------------------------------------------------- 5/1 PL/SQL: Statement ignored 5/1 PLS-00904: insufficient privilege to access object PROTECTEDPROC -
Switch to the
SampleUser1connection. Recreate theProtectedProcprocedure.sampleuser2: Command> use SampleUser1 sampleuser1: Command> CREATE OR REPLACE PROCEDURE ProtectedProc ACCESSIBLE BY (CallingProc, SampleUser2.CallingProc) AS BEGIN DBMS_OUTPUT.PUT_LINE ('SampleUser1 ProtectedProc'); END; / Procedure created. -
From the
SampleUser2connection, call theCallingProcprocedure. TheSampleUser2.CallingProcis in the white list of theSampleUser1.ProtectedProcprocedure, resulting in successful execution.sampleuser1: Command> use SampleUser2; sampleuser2: Command> SET SERVEROUTPUT ON sampleuser2: Command> exec CallingProc SampleUser2 CallingProc SampleUser1 ProtectedProc PL/SQL procedure successfully completed.
Using the CREATE PROCEDURE statement to retrieve information
Create a procedure query_emp to retrieve information about an employee. Pass the employee_id 171 to the procedure and retrieve the last_name and salary into two OUT parameters.
Command> CREATE OR REPLACE PROCEDURE query_emp
(p_id IN employees.employee_id%TYPE,
p_name OUT employees.last_name%TYPE,
p_salary OUT employees.salary%TYPE) IS
BEGIN
SELECT last_name, salary INTO p_name, p_salary
FROM employees
WHERE employee_id = p_id;
END query_emp;
/
Procedure created.CREATE PROFILE
The CREATE PROFILE statement creates a profile, which is a set of limits on the database resources. If you assign a profile to a user, that user cannot exceed the limits specified in the profile.
Required privilege
ADMIN
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
CREATE PROFILE profile LIMIT password_parameters password_parameters::= [FAILED_LOGIN_ATTEMPTS password_parameter_options] [PASSWORD_LIFE_TIME password_parameter_options] [PASSWORD_REUSE_TIME password_parameter_options] [PASSWORD_REUSE_MAX password_parameter_options] [PASSWORD_LOCK_TIME password_parameter_options] [PASSWORD_GRACE_TIME password_parameter_options] [{PASSWORD_COMPLEXITY_CHECKER|PASSWORD_VERIFY_FUNCTION} password_checker_options] password_parameter_options::= UNLIMITED|DEFAULT|constant password_checker_options::= function|NULL|DEFAULT function:: TT_VERIFY_FUNCTION|TT_STRONG_VERIFY_FUNCTION|TT_STIG_VERIFY_FUNCTION
Parameters
| Parameter | Description |
|---|---|
|
|
Name of the profile. |
|
|
The The password parameters consist of the name of the password parameter and the value (or limit) for the password parameter. This includes the password complexity checker functions. All the parameters (with the exception of If you do not specify a password parameter after the |
|
|
Specifies the number of consecutive failed attempts to connect to the database by a user before that user's account is locked. |
|
|
Specifies the number of days that a user can use the same password for authentication. If you also set a value for |
|
|
These two parameters must be used together.
You must specify a value for both parameters for them to have any effect. Specifically:
|
|
|
Specifies the number of days the user account is locked after the specified number of consecutive failed connection attempts. |
|
|
Specifies the number of days after the grace period begins during which TimesTen issues a warning, but allows the connection to the database. If the password is not changed during the grace period, the password expires. This parameter is associated with the |
|
|
Indicates that there is no limit for the password parameter. If you specify |
|
|
Indicates that you want to omit a limit for the password parameter in this profile. A user that is assigned this profile is subject to the limit defined in the If you specify |
|
|
Indicates the value of the password parameter if you do not specify |
|
|
Indicates if password verification is done on passwords and, if so, the function used for verification. You can specify either the function refers to one of the three supported password complexity checker functions. Specify one of these functions to direct TimesTen to perform password verification. Valid values:
If you do not specify the |
Description: PROFILE statement
-
Use the
CREATEPROFILEstatement to create a profile for the password resources, which is a set of limits for the password parameters. If you assign the profile to a user, the user cannot exceed the limits specified for the profile. If you do not assign a profile to a user, TimesTen assigns theDEFAULTprofile. See "Password management" in the Oracle TimesTen In-Memory Database Security Guide for more information on password management and profiles. -
To specify the password parameter limits for a user, do the following:
-
Use the
CREATEPROFILEstatement to create a profile that defines the password parameter limits. -
Use the
CREATEUSERorALTERUSERstatement to assign the profile to the user.
-
-
There is a
DEFAULTprofile that defines a limit for each of the password parameters. This profile initially definesUNLIMITEDfor these parameters (which indicates that no limit has been set for the parameter). The exceptions are:-
FAILED_LOGIN_ATTEMPTS: Set to10. -
PASSWORD_LOCK_TIME: Set to0.0034722222222222days (equal to 5 minutes, 5/1440 days) -
PASSWORD_COMPLEXITY_CHECKER: Set toNULL.
You can change these limits by using the
ALTERPROFILEstatement and specifying"DEFAULT"for the profile name. (Note thatDEFAULTmust be enclosed in double quotation marks.) See "ALTER PROFILE" for information. -
-
If a user is not assigned a profile, the user is subject to the limits defined in the
DEFAULTprofile. If a user is assigned a profile and that profile omits a limit on the password parameter or specifiesDEFAULTfor the password parameter, then the user is subject to the limits on those password parameters as defined by theDEFAULTprofile. -
The instance administrator is assigned a system profile. You cannot alter or drop the profile of an instance administrator.
About password complexity checker verification
Password complexity checker verification ensures the password for a user is complex enough to deter intruders who try to guess passwords. When you specify a password complexity checker function in the CREATE PROFILE statement, and then assign this profile to a user, the user must create a password that meets the requirements defined for the password complexity checker function. These requirements depend on the specific password complexity checker function that you specify.
TimesTen provides the TT_VERIFY_FUNCTION, the TT_STRONG_VERIFY_FUNCTION, and the TT_STIG_VERIFY_FUNCTION password complexity checker functions to manage the complexity of the passwords. These functions are stored in the SYS schema.
- letter: Uppercase and lowercase letters
- digit:
0-9numbers - special: A character that is neither a letter nor a digit.
`~!@#$%^&*()_-+={}[]\/<>,.?':|(space)Note:
-
If you use one or more of the special characters, the entire password must be enclosed in double quotation marks (
"). The exceptions are the#and the@special characters. (A password that contains the#or the@does not need to be enclosed in double quotation marks.) -
The password cannot contain a semicolon (
;) or a double quotation mark ("). -
The password must begin with a letter unless you enclose the entire password in double quotation marks.
-
You cannot define your own function for password complexity checker verification. The complexity of the password is checked when you use the IDENTIFIED BY clause in the CREATE USER or ALTER USER statements.
TT_VERIFY_FUNCTION
TT_VERIFY_FUNCTION does the following password complexity checker verification:
- A password:
- Must have at least 8 characters.
- Of these 8 characters, must contain at least one letter, at least one digit, and at least one special character. .
- A password cannot contain:
- Username or the username reversed
- Database name
OracleorTimesTen
Note:
The comparisons are case insensitive.
TT_STRONG_VERIFY_FUNCTION
TT_STRONG_VERIFY_FUNCTION performs the following password complexity checker verification:
- Must have at least 9 characters.
- Of these 9 characters, must contain at least two uppercase letters, at least two lowercase letters, at least two digits, and at least two special characters.
TT_STIG_VERIFY_FUNCTION
- Must have at least 15 characters.
- Of these 15 characters, must contain at least one uppercase letter, at least one lowercase letter, at least one digit, and at least one special character.
Description: Password complexity checker verification
EXECUTEprivilege onTT_VERIFY_FUNCTION,TT_STRONG_VERIFY_FUNCTION, andTT_STIG_VERIFY_FUNCTIONis required. TimesTen grants theEXECUTEprivilege on these functions toPUBLICby default.- The
SYSTEMand theDEFAULTprofiles are assigned a value of aNULLby default. ANULLvalue indicates that there is no password complexity checker function for these profiles, and as such, there is no password complexity checker verification done. - You cannot modify the
SYSTEMprofile to specify a password complexity checker function. Passwords for system users do not undergo password complexity checker verification. - You can use the
ALTERPROFILEstatement to modify theDEFAULTprofile to specify a password complexity checker function. You specify such a function in thePASSWORD_COMPLEXITY_CHECKER(orPASSWORD_VERIFY_FUNCTION) clause. - The
TT_VERIFY_FUNCTION,TT_STRONG_VERIFY_FUNCTION, andTT_STIG_VERIFY_FUNCTIONfunctions in TimesTen are equivalent to theORA12C_VERIFY_FUNCTION,ORA12C_STRONG_VERIFY_FUNCTION, andORA12C_STIG_VERIFY_FUNCTIONfunctions in Oracle Database. - If you use the
ttMigrateutility to downgrade to an earlier major release (such as the 18.1 release), thePASSWORD_COMPLEXITY_CHECKERvalue is set toNULLfor each profile in the database.
Restrictions on the password complexity checker functions
- You cannot specify the
SYSschema for the password complexity checker function. For example:Command> CREATE PROFILE my_profile LIMIT PASSWORD_COMPLEXITY_CHECKER SYS.TT_VERIFY_FUNCTION; 15187: Cannot specify schema name for password complexity checker function The command failed. - You cannot define your own password complexity checker function. Use only the
TT_VERIFY_FUNCTION,theTT_STRONG_VERIFY_FUNCTION, or theTT_STIG_VERIFY_FUNCTIONpassword complexity checker functions. - The password complexity checker verification is only done on a newly created password. You specify this new password by using the
IDENTIFIEDBYclause of theCREATEUSERor theALTERUSERstatement. TimesTen does not verify differences between an old and a new password. - Multi-byte characters are not supported when specifying passwords. TimesTen does not validate passwords with multi-byte characters.
Examples
These examples illustrate various uses of the CREATE PROFILE statement. The examples also show how to use the supported clauses:
- Examples illustrating password complexity checker verification:
- Additional examples:
Specify TT_VERIFY_FUNCTION for PASSWORD_COMPLEXITY_CHECKER
This example first creates a profile and specifies the TT_VERIFY_FUNCTION function. The example then queries the dba_profiles system view to verify the TT_VERIFY_FUNCTION has been assigned to this profile. A user who is assigned this profile must specify a password that meets the password verification requirements for this function.
Command> CREATE PROFILE myprofile_pw1 LIMIT
PASSWORD_COMPLEXITY_CHECKER TT_VERIFY_FUNCTION;
Profile created.
Command> SELECT * FROM dba_profiles WHERE profile = 'MYPROFILE_PW1';
< MYPROFILE_PW1, FAILED_LOGIN_ATTEMPTS, PASSWORD, DEFAULT >
< MYPROFILE_PW1, PASSWORD_LIFE_TIME, PASSWORD, DEFAULT >
< MYPROFILE_PW1, PASSWORD_REUSE_TIME, PASSWORD, DEFAULT >
< MYPROFILE_PW1, PASSWORD_REUSE_MAX, PASSWORD, DEFAULT >
< MYPROFILE_PW1, PASSWORD_COMPLEXITY_CHECKER, PASSWORD, TT_VERIFY_FUNCTION >
< MYPROFILE_PW1, PASSWORD_LOCK_TIME, PASSWORD, DEFAULT >
< MYPROFILE_PW1, PASSWORD_GRACE_TIME, PASSWORD, DEFAULT >
< MYPROFILE_PW1, TEMP_SPACE_PER_SESSION_MAX, MEMORY, DEFAULT >
8 rows found.
Create the sampleuser_pw1 user and assign the myprofile_pw1 profile to this user. Specify a password that meets the requirements of the TT_VERIFY_FUNCTION. See "TT_VERIFY_FUNCTION" for information on the TT_VERIFY_FUNCTION function.
Command> CREATE USER sampleuser_pw1
IDENTIFIED BY "A1!XXcg3" PROFILE myprofile_pw1;
User created.
Attempt to create the sampleuser_pw2. Assign the myprofile_pw1 profile to the user. Specify a password that contains the username reversed in uppercase. The CREATE USER statement fails. The password cannot contain the username reversed. Note that the comparison is case insensitive.
Command> CREATE USER sampleuser_pw2
IDENTIFIED BY "2WP_RESUELPMAS" PROFILE myprofile_pw1;
15186: Password complexity check for the specified password failed
15188: TT-20002: Password contains the username reversed
The command failed.Specify TT_STRONG_VERIFY_FUNCTION for PASSWORD_COMPLEXITY_CHECKER
This example creates the myprofile_pw2 profile and specifies TT_STRONG_VERIFY_FUNCTION for the PASSWORD_COMPLEXITY_CHECKER password parameter. The example then creates the sampleuser_pw2 user, assigns the myprofile_pw2 profile to the user. The password meets the requirements of the TT_STRONG_VERIFY_FUNCTION function. See "TT_STRONG_VERIFY_FUNCTION" for more information on the TT_STRONG_VERIFY_FUNCTION function.
Command> CREATE PROFILE myprofile_pw2 LIMIT
PASSWORD_COMPLEXITY_CHECKER TT_STRONG_VERIFY_FUNCTION;
Profile created.Create the sampleuser_pw2, assign the myprofile_pw2 profile to the user. The password meets the requirements of the TT_STRONG_VERIFY_FUNCTION function. The user is successfully created.
Command> CREATE USER sampleuser_pw2
IDENTIFIED BY "!ddFF6C2?" PROFILE myprofile_pw2;
User created.Specify TT_STIG_VERIFY_FUNCTION for PASSWORD_COMPLEXITY_CHECKER
This example creates the myprofile_pw3 profile and specifies TT_STIG_VERIFY_FUNCTION for the PASSWORD_COMPLEXITY_CHECKER password parameter. The example then creates the sampleuser_pw3 user, assigns the myprofile_pw3 profile to the user. The password meets the requirements of the TT_STIG_VERIFY_FUNCTION function. See "TT_STIG_VERIFY_FUNCTION" for more information on the TT_STIG_VERIFY_FUNCTION function.
Command> CREATE PROFILE myprofile_pw3 LIMIT
PASSWORD_COMPLEXITY_CHECKER TT_STIG_VERIFY_FUNCTION;
Profile created.Create the sampleuser_pw3, assign the myprofile_pw3 profile to the user. The password meets the requirements of the TT_STIG_VERIFY_FUNCTION function. The user is successfully created.
Command> CREATE USER sampleuser_pw3
IDENTIFIED BY "!ddBBKKUYT165>m" PROFILE myprofile_pw3;
User created.Modify PASSWORD_COMPLEXITY_CHECKER value for SYSTEM and DEFAULT
This example queries the dba_profiles system view to check the value of the PASSWORD_COMPLEXITY_CHECKER password parameter for the SYSTEM and the DEFAULT profiles. The value is NULL by default.
Command> SELECT * FROM dba_profiles WHERE
resource_name='PASSWORD_COMPLEXITY_CHECKER' AND
profile IN ('DEFAULT','SYSTEM');
< DEFAULT, PASSWORD_COMPLEXITY_CHECKER, PASSWORD, NULL >
< SYSTEM, PASSWORD_COMPLEXITY_CHECKER, PASSWORD, NULL >
2 rows found.Attempt to modify the PASSWORD_COMPLEXITY_CHECKER password parameter for the SYSTEM profile. An error results as this password parameter cannot be modified.
Command> ALTER PROFILE SYSTEM LIMIT
PASSWORD_COMPLEXITY_CHECKER TT_STRONG_VERIFY_FUNCTION;
15176: Profile SYSTEM cannot be altered
The command failed.Attempt to modify the PASSWORD_COMPLEXITY_CHECKER password parameter for the DEFAULT profile. The modification is successful. A user who is assigned the DEFAULT profile, or is not assigned a profile, must specify a password that meets the password verification requirements for the TT_STRONG_VERIFY_FUNCTION function.
Command> ALTER PROFILE "DEFAULT" LIMIT
PASSWORD_COMPLEXITY_CHECKER TT_STRONG_VERIFY_FUNCTION;
Profile alteredQuery the dba_profiles view to verify the TT_STRONG_VERIFY_FUNCTION has been assigned to the DEFAULT profile.
Command> SELECT * FROM dba_profiles WHERE
resource_name='PASSWORD_COMPLEXITY_CHECKER' AND
profile = 'DEFAULT';
< DEFAULT, PASSWORD_COMPLEXITY_CHECKER, PASSWORD, TT_STRONG_VERIFY_FUNCTION >
1 row found.Create a profile and attempt to specify an invalid password complexity checker function
This example specifies an invalid password complexity checker function for the PASSWORD_COMPLEXITY_CHECKER clause. Even though this function resides in the SYS schema, an error results, as you can only specify one of the three supported password complexity checker functions.
Command> CREATE PROFILE myprofile1 LIMIT
PASSWORD_COMPLEXITY_CHECKER TT_COMPLEXITY_CHECK;
8529: Invalid password complexity checker function TT_COMPLEXITY_CHECK
The command failed.Create a profile and set limits on the password parameters
This example creates the profile1 profile and sets various limits on the password parameters. It then queries the dba_profiles system view to verify the limits.
Command> CREATE PROFILE profile1 LIMIT
FAILED_LOGIN_ATTEMPTS 5
PASSWORD_LIFE_TIME 60
PASSWORD_REUSE_TIME 60
PASSWORD_REUSE_MAX 5
PASSWORD_LOCK_TIME 1
PASSWORD_GRACE_TIME 10;
Profile created.Query the dba_profiles system view to verify the limits. Note that since the PASSWORD_COMPLEXITY_CHECKER password parameter was not specified in the CREATE PROFILE statement, the value of PASSWORD_COMPLEXITY_CHECKER is DEFAULT (the value comes from the value that is in the DEFAULT profile).
Command> SELECT * FROM dba_profiles WHERE profile = 'PROFILE1' AND
resource_type='PASSWORD';
< PROFILE1, FAILED_LOGIN_ATTEMPTS, PASSWORD, 5 >
< PROFILE1, PASSWORD_LIFE_TIME, PASSWORD, 60 >
< PROFILE1, PASSWORD_REUSE_TIME, PASSWORD, 60 >
< PROFILE1, PASSWORD_REUSE_MAX, PASSWORD, 5 >
< PROFILE1, PASSWORD_COMPLEXITY_CHECKER, PASSWORD, DEFAULT >
< PROFILE1, PASSWORD_LOCK_TIME, PASSWORD, 1 >
< PROFILE1, PASSWORD_GRACE_TIME, PASSWORD, 10 >
7 rows found.Create a profile and specify FAILED_LOGIN_ATTEMPTS
This example creates the profile2 profile and specifies a value of 1 for FAILED_LOGIN_ATTEMPTS. The example then creates the user2 user and assigns user2 the profile2 profile. The user2 user attempts to connect to the database, but specifies an invalid password. The connection fails. After five minutes, the user2 user attempts to reconnect to the database. The connection succeeds due to the 0.0034722222222222 (equal to 5 minutes) value for PASSWORD_LOCK_TIME (specified in the DEFAULT profile).
Command> CREATE PROFILE profile2 LIMIT FAILED_LOGIN_ATTEMPTS 1; Profile created. Command> CREATE USER user2 IDENTIFIED BY user2 PROFILE profile2; User created.
Grant admin privilege to user2.
Command> GRANT ADMIN TO user2;
Attempt to connect to the database. The connection fails due to an invalid password specified in the connection string.
Command> connect adding "UID=user2;PWD=user3" as user2; 7001: User authentication failed The command failed.
Attempt to connect again specifying the correct password in the connection string. The connection fails due to:
-
One previous failed connection attempt
-
An attempt to connect to the database before the five minute password lock time.
none: Command> use database1 database1: Command> connect adding "UID=user2;PWD=user2" as user2; 15179: the account is locked The command failed.
After five minutes, attempt to connect to the database again. The connection succeeds.
none: Command> use database1 database1: Command> connect adding "UID=user2;PWD=user2" as user2; Connection successful: DSN=database1;UID=user2;DataStore=/scratch/database1; DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=AL32UTF8;PermSize=128; (Default setting AutoCommit=1)
Determine the password parameter values in the DEFAULT profile
This example queries the dba_profiles system view to determine the password parameter values for the DEFAULT profile.
Command> SELECT * FROM dba_profiles WHERE profile = 'DEFAULT' AND
resource_type='PASSWORD';
< DEFAULT, FAILED_LOGIN_ATTEMPTS, PASSWORD, 10 >
< DEFAULT, PASSWORD_LIFE_TIME, PASSWORD, UNLIMITED >
< DEFAULT, PASSWORD_REUSE_TIME, PASSWORD, UNLIMITED >
< DEFAULT, PASSWORD_REUSE_MAX, PASSWORD, UNLIMITED >
< DEFAULT, PASSWORD_COMPLEXITY_CHECKER, PASSWORD, NULL >
< DEFAULT, PASSWORD_LOCK_TIME, PASSWORD, .0034 >
< DEFAULT, PASSWORD_GRACE_TIME, PASSWORD, UNLIMITED >
7 rows found.Specify PASSWORD_LIFE_TIME and PASSWORD_GRACE_TIME
This example creates the profile4 profile and specifies a value of 0.0034722222222222 (equal to 5 minutes) for the PASSWORD_LIFE_TIME password parameter and a value of 0.01041667 (equal to 15 minutes) for the PASSWORD_GRACE_TIME password parameter. It then creates the user4 user and assigns the profile4 profile to user4. The example continues with attempts to connect to the database as user4.
Command> CREATE PROFILE profile4 LIMIT
PASSWORD_LIFE_TIME 0.0034722222222222
PASSWORD_GRACE_TIME 0.01041667;
Profile created.Query the dba_profiles system view to verify the values for the password parameters.
Command> SELECT * FROM dba_profiles WHERE profile = 'PROFILE4' AND
resource_type='PASSWORD';
< PROFILE2, FAILED_LOGIN_ATTEMPTS, PASSWORD, DEFAULT >
< PROFILE2, PASSWORD_LIFE_TIME, PASSWORD, .0034 >
< PROFILE2, PASSWORD_REUSE_TIME, PASSWORD, DEFAULT >
< PROFILE2, PASSWORD_REUSE_MAX, PASSWORD, DEFAULT >
< PROFILE2, PASSWORD_COMPLEXITY_CHECKER, PASSWORD, DEFAULT >
< PROFILE2, PASSWORD_LOCK_TIME, PASSWORD, DEFAULT >
< PROFILE2, PASSWORD_GRACE_TIME, PASSWORD, .0104 >
7 rows found.Create the user4 user and assign user4 the profile4 profile. Grant the CONNECT privilege to user4.
Command> CREATE USER user4 IDENTIFIED BY user4 PROFILE profile4; User created. Command> GRANT CONNECT TO user4;
Connect to the database as user4. The connection succeeds.
Command> connect adding "UID=user4;PWD=user4" as user4; Connection successful: DSN=access1;UID=user4;DataStore=/scratch/database1; DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=AL32UTF8;PermSize=128; (Default setting AutoCommit=1)
Disconnect from the database. After 5 minutes, reconnect to the database as user4. The connection succeeds but a warning is issued. The password lifetime is 5 minutes and the password grace time is 15 minutes.
user4: Command> disconnect user4; Disconnecting from user4... none: Command> use database1 database1: Command> connect adding "UID=user4;PWD=user4" as user4; Warning 15182: Password will expire within 0.010417 days Connection successful: DSN=access1;UID=user4;DataStore=/scratch/database1; DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=AL32UTF8;PermSize=128; (Default setting AutoCommit=1)
Disconnect from the database. After 15 minutes, reconnect to the database as user4. The connection fails as the password grace time of 15 minutes has ended.
user4: Command> disconnect user4; Disconnecting from user4... none: Command> use database1 database1: Command> connect adding "UID=user4;PWD=user4" as user4; 15180: the password has expired The command failed.
Create a profile specifying only the LIMIT keyword
This example creates the profile5 profile and specifies just the LIMIT keyword. The example then queries the dba_profiles system view to illustrate the password parameter limits for the profile5 profile are all set to a value of DEFAULT.
Command> CREATE PROFILE profile5 LIMIT;
Profile created.
Command> SELECT * FROM dba_profiles WHERE profile = 'PROFILE5' AND
resource_type='PASSWORD
< PROFILE5, FAILED_LOGIN_ATTEMPTS, PASSWORD, DEFAULT >
< PROFILE5, PASSWORD_LIFE_TIME, PASSWORD, DEFAULT >
< PROFILE5, PASSWORD_REUSE_TIME, PASSWORD, DEFAULT >
< PROFILE5, PASSWORD_REUSE_MAX, PASSWORD, DEFAULT >
< PROFILE5, PASSWORD_COMPLEXITY_CHECKER, PASSWORD, DEFAULT >
< PROFILE5, PASSWORD_LOCK_TIME, PASSWORD, DEFAULT >
< PROFILE5, PASSWORD_GRACE_TIME, PASSWORD, DEFAULT >
7 rows found.Specify UNLIMITED for PASSWORD_REUSE_TIME
This example creates the profile6 profile and specifies a PASSWORD_REUSE_TIME of UNLIMITED. The password cannot be reused.
Command> CREATE PROFILE profile6 LIMIT
PASSWORD_REUSE_MAX 2
PASSWORD_REUSE_TIME UNLIMITED;
Profile created.Create the user6 user and assign user6 the profile6 profile. Change the user6 password two times. Attempt to reuse the user6 password. The attempt fails due to the PASSWORD_REUSE_TIME value of UNLIMITED.
Command> CREATE USER user6 IDENTIFIED BY user6 PROFILE profile6; User created. Command> ALTER USER user6 IDENTIFIED BY user6_test1; User altered. Command> ALTER USER user6 IDENTIFIED BY user6_test2; User altered. Command> ALTER USER user6 IDENTIFIED BY user6; 15183: Password cannot be reused The command failed.
Specify DEFAULT for PASSWORD_REUSE_TIME
This example creates the profile7 profile, specifying the value of DEFAULT for the PASSWORD_REUSE_TIME password parameter and the value of 3 for the PASSWORD_REUSE_MAX password parameter. TimesTen uses the value in the DEFAULT profile for the PASSWORD_REUSE_TIME password parameter.
Command> CREATE PROFILE profile7 LIMIT
PASSWORD_REUSE_TIME DEFAULT
PASSWORD_REUSE_MAX 3;
Profile created.Query the dba_profiles system view to verify the password parameter values for the profile7 profile. Note the value of DEFAULT for PASSWORD_REUSE_TIME and a value of 3 for PASSWORD_REUSE_MAX (represented in bold).
Command> SELECT * FROM dba_profiles WHERE profile = 'PROFILE7' AND
resource_type = 'PASSWORD';
< PROFILE7, FAILED_LOGIN_ATTEMPTS, PASSWORD, DEFAULT >
< PROFILE7, PASSWORD_LIFE_TIME, PASSWORD, DEFAULT >
< PROFILE7, PASSWORD_REUSE_TIME, PASSWORD, DEFAULT >
< PROFILE7, PASSWORD_REUSE_MAX, PASSWORD, 3 >
< PROFILE7, PASSWORD_COMPLEXITY_CHECKER, PASSWORD, DEFAULT >
< PROFILE7, PASSWORD_LOCK_TIME, PASSWORD, DEFAULT >
< PROFILE7, PASSWORD_GRACE_TIME, PASSWORD, DEFAULT >
7 rows found.Query the dba_profiles system view to verify the password parameter values for the DEFAULT profile. Note the value of UNLIMITED for PASSWORD_REUSE_TIME (represented in bold).
Command> SELECT * FROM dba_profiles WHERE profile = 'DEFAULT' AND
resource_type = 'PASSWORD';
< DEFAULT, FAILED_LOGIN_ATTEMPTS, PASSWORD, 10 >
< DEFAULT, PASSWORD_LIFE_TIME, PASSWORD, UNLIMITED >
< DEFAULT, PASSWORD_REUSE_TIME, PASSWORD, UNLIMITED >
< DEFAULT, PASSWORD_REUSE_MAX, PASSWORD, UNLIMITED >
< DEFAULT, PASSWORD_COMPLEXITY_CHECKER, PASSWORD, NULL >
< DEFAULT, PASSWORD_LOCK_TIME, PASSWORD, .0034 >
< DEFAULT, PASSWORD_GRACE_TIME, PASSWORD, UNLIMITED >
7 rows found.Create the user7 user and assign the profile7 profile to user7. Change the user7 password three times. The user7 password cannot be reused due to the value of UNLIMITED for the PASSWORD_REUSE_TIME parameter.
Command> CREATE USER user7 IDENTIFIED BY user7 PROFILE profile7; User created. Command> ALTER USER user7 IDENTIFIED BY user7_test1; User altered. Command> ALTER USER user7 IDENTIFIED BY user7_test2; User altered. Command> ALTER USER user7 IDENTIFIED BY user_test3; User altered. Command> ALTER USER user7 IDENTIFIED BY user7; 15183: Password cannot be reused The command failed.
Specify PASSWORD_REUSE_TIME and PASSWORD_REUSE_MAX
This example creates the profile8 profile, specifying a value of 0.0020833 (equal to approximately 2 minutes) for the PASSWORD_REUSE_TIME password parameter and a value of 2 for the PASSWORD_REUSE_MAX password parameter. The example then creates the user8 user and assigns user8 the profile8 profile. The user8 password is changed two times within two minutes. Then, still within the two minutes, the original user8 password (user8_pwd) is reused. The ALTER USER operation fails. Even though the password is changed 2 times, the original password can only be reused after 0.00208333 days (equal to approximately two minutes). After two minutes, the original user8 password (user8_pwd) is reused again. The ALTER USER operation succeeds. The user's password was changed two times and more than two minutes had passed.
Command> CREATE PROFILE profile8 LIMIT
PASSWORD_REUSE_TIME 0.00208333
PASSWORD_REUSE_MAX 2;
Profile created.Create the user8 user and assign user8 the profile8 profile.
Command> CREATE USER user8 IDENTIFIED BY user8_pwd PROFILE profile8; User created.
Immediately alter the user, changing the password two times.
Command> ALTER USER user8 IDENTIFIED BY user8_test1; User altered. Command> ALTER USER user8 IDENTIFIED BY user8_test2; User altered.
Within two minutes, attempt to reuse the original user8_pwd password (represented in bold). The ALTER USER operation fails as the original password can only be reused after two minutes.
Command> ALTER USER user8 IDENTIFIED BY user8_pwd;
15183: Password cannot be reused
The command failed.After two minutes, attempt to reuse the original user8_pwd password (represented in bold). The ALTER USER operation succeeds. The original password can be reused as the password was changed two times and two minutes had expired.
Command> ALTER USER user8 IDENTIFIED BY user8_pwd;
User altered.CREATE REPLICATION
This statement is not supported in TimesTen Scaleout.
In TimesTen Classic:
The CREATE REPLICATION statement:
-
Defines a classic replication scheme on a participating database.
-
Installs the specified configuration in the executing database's replication system tables.
-
Typically consists of one or more replication element specifications and zero or more
STOREspecifications.
TimesTen SQL configuration for replication also provides a programmable way to configure a classic replication scheme. The configuration can be embedded in C, C++ or Java code. Replication can be configured locally or from remote systems using client/server.
In addition, you need to use the ttRepAdmin utility to maintain operations not covered by the supported SQL statements. Use ttRepAdmin to change replication state, duplicate databases, list the replication configuration, and view replication status.
Required privilege
ADMIN
Usage with TimesTen Scaleout
This statement is not supported with TimesTen Scaleout.
Definitions
A replication element is an entity that TimesTen synchronizes between databases. A replication element can be a whole table or a database. A database can include most types of tables and sequences. It can include only specified tables and sequences, or include all tables except specified tables and sequences. It cannot include temporary tables or views, whether materialized or nonmaterialized.
A replication scheme is a set of replication elements, as well as the databases that maintain copies of these elements.
For more detailed information on SQL configuration for classic replication, see "Defining a classic replication scheme" in the Oracle TimesTen In-Memory Database Replication Guide.
SQL syntax
CREATE REPLICATION [Owner.]ReplicationSchemeName { ELEMENT ElementName { DATASTORE | { TABLE [Owner.]TableName [CheckConflicts]} | SEQUENCE [Owner.]SequenceName} { MASTER | PROPAGATOR } FullStoreName [TRANSMIT { NONDURABLE | DURABLE }] { SUBSCRIBER FullStoreName [,...] [ReturnServiceAttribute] } [,...] } [...] [{INCLUDE | EXCLUDE} {TABLE [[Owner.]TableName[,...]] | SEQUENCE [[Owner.]SequenceName[,...]} [,...]] [ STORE FullStoreName [StoreAttribute [... ]]] [...] [ NetworkOperation[...]]
See "CHECK CONFLICTS" for CheckConflicts syntax.
Syntax for ReturnServiceAttribute:
{ RETURN RECEIPT [BY REQUEST] |
RETURN TWOSAFE [BY REQUEST] |
NO RETURN }
Syntax for StoreAttribute:
DISABLE RETURN {SUBSCRIBER | ALL} NumFailures
RETURN SERVICES {ON | OFF} WHEN [REPLICATION] STOPPED
DURABLE COMMIT {ON | OFF}
RESUME RETURN Milliseconds
LOCAL COMMIT ACTION {NO ACTION | COMMIT}
RETURN WAIT TIME Seconds
COMPRESS TRAFFIC {ON | OFF}
PORT PortNumber
TIMEOUT Seconds
FAILTHRESHOLD Value
CONFLICT REPORTING SUSPEND AT Value
CONFLICT REPORTING RESUME AT Value
TABLE DEFINITION CHECKING {RELAXED|EXACT}
Syntax for NetworkOperation:
ROUTE MASTER FullStoreName SUBSCRIBER FullStoreName { { MASTERIP MasterHost | SUBSCRIBERIP SubscriberHost } PRIORITY Priority } [...]
Parameters
| Parameter | Description |
|---|---|
|
|
Name assigned to the new classic replication scheme. Classic replication schemes should have names that are unique from all other database objects. |
|
|
Check for replication conflicts when simultaneously writing to bidirectionally replicated databases. See "CHECK CONFLICTS" for information on |
|
|
Compress replicated traffic to reduce the amount of network bandwidth. |
|
|
Suspends conflict resolution reporting.
This clause is valid for table level replication. |
|
|
Resumes conflict resolution reporting.
This clause is valid for table level replication. |
|
|
Define entire database as element. This type of element can only be defined for a master database that is not configured with an element of type |
|
|
|
|
|
Set the return service failure policy so that return service blocking is disabled after the number of timeouts specified by If |
|
|
Overrides the |
|
|
The entity that TimesTen synchronizes between databases. TimesTen supports the entire database (
See "Defining replication elements" in Oracle TimesTen In-Memory Database Replication Guide for details. |
|
|
The number of log files that can accumulate for a subscriber database. If this value is exceeded, the subscriber is set to the See "Setting the transaction log failure threshold" in Oracle TimesTen In-Memory Database Replication Guide. |
|
|
The database, specified as one of the following:
For example, if the database path is This is the database file name specified in the
|
|
|
Specifies the default action to be taken for a return twosafe transaction in the event of a timeout. Note: This attribute is only valid when the
This setting can be overridden for specific transactions by calling the |
|
|
The database on which applications update the specified element. The |
|
|
Specifies that no return service is to be used. This is the default. For details on the use of the return services, see "Using a return service" in Oracle TimesTen In-Memory Database Replication Guide. |
|
|
The TCP/IP port number on which the replication agent for the database listens for connections. If not specified, the replication agent automatically allocates a port number. |
|
|
The database that receives replicated updates and passes them on to other databases. The |
|
|
If return service blocking has been disabled by If |
|
|
Enables the return receipt service, so that applications that commit a transaction to a master database are blocked until the transaction is received by all subscribers.
|
|
|
Sets return services on or off when replication is disabled (stopped or paused state).
|
|
|
Enables the return twosafe service, so that applications that commit a transaction to a master database are blocked until the transaction is committed on all subscribers. Note: This service can only be used in a bidirectional replication scheme where the elements are defined as Specifying |
|
|
Specifies the number of seconds to wait for return service acknowledgment. The default value is 10 seconds. A value of 0 (zero) means that there is no timeout. Your application can override this timeout setting by calling the |
|
|
Define the sequence specified by |
|
|
Defines the attributes for a given database. Attributes include |
|
|
A database that receives updates from the |
|
|
Define the table specified by |
|
|
The maximum number of seconds the replication agent waits for a response from remote replication agents. The default is 120 seconds. Note: For large transactions that may cause a delayed response from the remote replication agent, the agent scales the timeout based on the size of the transaction. This scaling is disabled if you set |
|
|
Specifies whether to flush the master log to the file system before sending a batch of committed transactions to the subscribers.
Note: Note: See "Setting transmit durability on DATASTORE element" in Oracle TimesTen In-Memory Database Replication Guide for more information. |
|
|
Specifies type of table definition checking that occurs on the subscriber:
The default is Note: If you use |
|
|
Denotes the Can be specified more than once. For |
|
|
Clause can be specified more than once. |
|
|
Variable expressed as an integer from 1 to 99. Denotes the priority of the IP address. Lower integral values have higher priority. An error is returned if multiple addresses with the same priority are specified. Controls the order in which multiple IP addresses are used to establish peer connections. Required syntax of |
CHECK CONFLICTS
Syntax
The syntax for CHECK CONFLICTS is:
{NO CHECK |
CHECK CONFLICTS BY ROW TIMESTAMP
COLUMN ColumnName
[ UPDATE BY { SYSTEM | USER } ]
[ ON EXCEPTION { ROLLBACK [ WORK ] | NO ACTION } ]
[ {REPORT TO 'FileName'
[ FORMAT { XML | STANDARD } ] | NO REPORT
} ]
}Note:
A CHECK CONFLICT clause can only be used for elements of type TABLE.
Parameters
The CHECK CONFLICTS clause of the CREATE REPLICATION or ALTER REPLICATION statement has the following parameters:
| Parameter | Description |
|---|---|
|
|
Indicates that all update and uniqueness conflicts are to be detected. Conflicts are resolved in the manner specified by the It also detects delete conflicts with |
|
|
Indicates the column in the replicated table to be used for timestamp comparison. The table is specified in the
|
|
|
Specify to suppress conflict resolution for a given element. |
|
|
Specifies whether the timestamp values are maintained by TimesTen ( |
|
|
Specifies how to resolve a detected conflict.
The default is |
|
|
Specifies the file to log updates that fail the timestamp comparison. |
|
|
Optionally specifies the conflict report format for an element. The default format is |
|
|
Specify to suppress logging of failed timestamp comparisons. |
Description
-
The names of all databases on the same host must be unique for each classic replication scheme for each TimesTen instance.
-
Replication elements can only be updated (by normal application transactions) through the
MASTERdatabase.PROPAGATORandSUBSCRIBERdatabases are read-only. -
If you define a classic replication scheme that permits multiple databases to update the same table, see "Resolving Replication Conflicts" in Oracle TimesTen In-Memory Database Replication Guide for recommendations on how to avoid conflicts when updating rows.
-
SELFis intended for classic replication schemes where all participating databases are local. Do not useSELFfor a distributed classic replication scheme in a production environment, where spelling out the host name for each database in a script enables it to be used at each participating database. -
Each attribute for a given
STOREmay be specified only once, or not at all. -
Specifying the
PORTof a database for one classic replication scheme specifies it for all classic replication schemes. All other connection attributes are specific to the classic replication scheme specified in the command. -
For replication schemes,
DataStoreNameis always the prefix of the TimesTen database checkpoint file names. These are the files with the.ds0and.ds1suffixes that are saved on the file system by checkpoint operations. -
If a row with a default
NOT INLINE VARCHARvalue is replicated, the receiver creates a copy of this value for each row instead of pointing to the default value if and only if the default value of the receiving node is different from the sending node. -
To use timestamp comparison on replicated tables, you must specify a nullable column of type
BINARY(8)to hold the timestamp value. Define the timestamp column when you create the table. You cannot add the timestamp column with theALTER TABLEstatement. In addition, the timestamp column cannot be part of a primary key or index. -
If you specify the XML report format, two XML documents are generated:
-
FileName.xml: This file contains the DTD for the report and the root node for the report. It includes the document definition and the include directive. -
FileName.include: This file is included inFileName.xmland contains all the actual conflicts. -
The
FileName.includefile can be truncated. Do not truncate theFileName.xmlfile. -
For a complete description of the XML format, including examples of each conflict, see "Reporting conflicts to an XML file" in Oracle TimesTen In-Memory Database Replication Guide.
-
-
If you specify a report format for an element and then drop the element, the corresponding report files are not deleted.
-
Use the
CONFLICT REPORTING SUSPEND ATclause to specify a high water mark threshold at which the reporting of conflict resolution is suspended. -
Use the
CONFLICT REPORTING RESUME ATclause to specify a low water mark threshold where the reporting of conflict resolution is resumed. When the rate of conflict falls below the low water mark threshold, conflict resolution reporting is resumed. -
The state of whether conflict reporting is suspended or not by a replication agent does not persist across the local replication agent and the peer agent stop and restart.
-
Do not use the
CREATE REPLICATIONstatement to replicate cache groups. Only active standby pairs can replicate cache groups. See theCREATE ACTIVE STANDBY PAIRstatement.
Examples
Replicate the contents of repl.tab from masterds to two subscribers, subscriber1ds and subscriber2ds.
CREATE REPLICATION repl.twosubscribers ELEMENT e TABLE repl.tab MASTER masterds ON "server1" SUBSCRIBER subscriber1ds ON "server2", subscriber2ds ON "server3";
Replicate the entire masterds database to the subscriber, subscriber1ds. The FAILTHRESHOLD specifies that a maximum of 10 log files can accumulate on masterds before it decides that subscriber1ds has failed.
CREATE REPLICATION repl.wholestore ELEMENT e DATASTORE MASTER masterds ON "server1" SUBSCRIBER subscriber1ds ON "server2" STORE masterds FAILTHRESHOLD 10;
Bidirectionally replicate the entire westds and eastds databases and enable the RETURN TWOSAFE service.
CREATE REPLICATION repl.biwholestore ELEMENT e1 DATASTORE MASTER westds ON "westcoast" SUBSCRIBER eastds ON "eastcoast" RETURN TWOSAFE ELEMENT e2 DATASTORE MASTER eastds ON "eastcoast" SUBSCRIBER westds ON "westcoast" RETURN TWOSAFE;
Enable the return receipt service for select transaction updates to the subscriber1ds subscriber.
CREATE REPLICATION repl.twosubscribers ELEMENT e TABLE repl.tab MASTER masterds ON "server1" SUBSCRIBER subscriber1ds ON "server2" RETURN RECEIPT BY REQUEST SUBSCRIBER subscriber2ds ON "server3";
Replicate the contents of the customerswest table from the west database to the ROUNDUP database and the customerseast table from the east database. Enable the return receipt service for all transactions.
CREATE REPLICATION r ELEMENT west TABLE customerswest MASTER west ON "serverwest" SUBSCRIBER roundup ON "serverroundup" RETURN RECEIPT ELEMENT east TABLE customerseast MASTER east ON "servereast" SUBSCRIBER roundup ON "serverroundup" RETURN RECEIPT;
Replicate the contents of the repl.tab table from the centralds database to the propds database, which propagates the changes to the backup1ds and backup2ds databases.
CREATE REPLICATION repl.propagator ELEMENT a TABLE repl.tab MASTER centralds ON "finance" SUBSCRIBER proprds ON "nethandler" ELEMENT b TABLE repl.tab PROPAGATOR proprds ON "nethandler" SUBSCRIBER backup1ds ON "backupsystem1" bakcup2ds ON "backupsystem2";
Bidirectionally replicate the contents of the repl.accounts table between the eastds and westds databases. Each database is both a master and a subscriber for the repl.accounts table.
Because the repl.accounts table can be updated on either the eastds or westds database, it includes a timestamp column (tstamp). The CHECK CONFLICTS clause establishes automatic timestamp comparison to detect any update conflicts between the two databases. In the event of a comparison failure, the entire transaction that includes an update with the older timestamp is rolled back (discarded).
CREATE REPLICATION repl.r1 ELEMENT elem_accounts_1 TABLE repl.accounts CHECK CONFLICTS BY ROW TIMESTAMP COLUMN tstamp UPDATE BY SYSTEM ON EXCEPTION ROLLBACK MASTER westds ON "westcoast" SUBSCRIBER eastds ON "eastcoast" ELEMENT elem_accounts_2 TABLE repl.accounts CHECK CONFLICTS BY ROW TIMESTAMP COLUMN tstamp UPDATE BY SYSTEM ON EXCEPTION ROLLBACK MASTER eastds ON "eastcoast" SUBSCRIBER westds ON "westcoast";
Replicate the contents of the repl.accounts table from the activeds database to the backupds database, using the return twosafe service, and using TCP/IP port 40000 on activeds and TCP/IP port 40001 on backupds. The transactions on activeds need to be committed whenever possible, so configure replication so that the transaction is committed even after a replication timeout using LOCAL COMMIT ACTION, and so that the return twosafe service is disabled when replication is stopped. To avoid significant delays in the application if the connection to the backupds database is interrupted, configure the return service to be disabled after five transactions have timed out, but also configure the return service to be re-enabled when the backupds database's replication agent responds in under 100 milliseconds. Finally, the bandwidth between databases is limited, so configure replication to compress the data when it is replicated from the activeds database.
CREATE REPLICATION repl.r ELEMENT elem_accounts_1 TABLE repl.accounts MASTER activeds ON "active" SUBSCRIBER backupds ON "backup" RETURN TWOSAFE ELEMENT elem_accounts_2 TABLE repl.accounts MASTER activeds ON "active" SUBSCRIBER backupds ON "backup" RETURN TWOSAFE STORE activeds ON "active" PORT 40000 LOCAL COMMIT ACTION COMMIT RETURN SERVICES OFF WHEN REPLICATION STOPPED DISABLE RETURN SUBSCRIBER 5 RESUME RETURN 100 COMPRESS TRAFFIC ON STORE backupds ON "backup" PORT 40001;
Illustrate conflict reporting suspend and conflict reporting resume clauses for table level replication. Use these clauses for table level replication not database replication. Issue repschemes command to show that replication scheme is created.
Command> CREATE TABLE repl.accounts (tstamp BINARY (8) NOT NULL
PRIMARY KEY, tstamp1 BINARY (8));
Command> CREATE REPLICATION repl.r2
ELEMENT elem_accounts_1 TABLE repl.accounts
CHECK CONFLICTS BY ROW TIMESTAMP
COLUMN tstamp1
UPDATE BY SYSTEM
ON EXCEPTION ROLLBACK WORK
MASTER westds ON "west1"
SUBSCRIBER eastds ON "east1"
ELEMENT elem_accounts_2 TABLE repl.accounts
CHECK CONFLICTS BY ROW TIMESTAMP
COLUMN tstamp1
UPDATE BY SYSTEM
ON EXCEPTION ROLLBACK WORK
MASTER eastds ON "east1"
SUBSCRIBER westds ON "west1"
STORE westds
CONFLICT REPORTING SUSPEND AT 20
CONFLICT REPORTING RESUME AT 10;
Command> REPSCHEMES;
Replication Scheme REPL.R2:
Element: ELEM_ACCOUNTS_1
Type: Table REPL.ACCOUNTS
Conflict Check Column: TSTAMP1
Conflict Exception Action: Rollback Work
Conflict Timestamp Update: System
Conflict Report File: (none)
Master Store: WESTDS on WEST1 Transmit Durable
Subscriber Store: EASTDS on EAST1
Element: ELEM_ACCOUNTS_2
Type: Table REPL.ACCOUNTS
Conflict Check Column: TSTAMP1
Conflict Exception Action: Rollback Work
Conflict Timestamp Update: System
Conflict Report File: (none)
Master Store: EASTDS on EAST1 Transmit Durable
Subscriber Store: WESTDS on WEST1
Store: EASTDS on EAST1
Port: (auto)
Log Fail Threshold: (none)
Retry Timeout: 120 seconds
Compress Traffic: Disabled
Store: WESTDS on WEST1
Port: (auto)
Log Fail Threshold: (none)
Retry Timeout: 120 seconds
Compress Traffic: Disabled
Conflict Reporting Suspend: 20
Conflict Reporting Resume: 10
1 replication scheme found.
Example of NetworkOperation clause with 2 MASTERIP and SUBSCRIBERIP clauses:
CREATE REPLICATION r ELEMENT e DATASTORE MASTER rep1 SUBSCRIBER rep2 RETURN RECEIPT MASTERIP "1.1.1.1" PRIORITY 1 SUBSCRIBERIP "2.2.2.2" PRIORITY 1 MASTERIP "3.3.3.3" PRIORITY 2 SUBSCRIBERIP "4.4.4.4" PRIORITY 2;
Example of NetworkOperation clause. Use the default sending interface but a specific receiving network:
CREATE REPLICATION r ELEMENT e DATASTORE MASTER rep1 SUBSCRIBER rep2 ROUTE MASTER rep1 ON "machine1" SUBSCRIBER rep2 ON "machine2" SUBSCRIBERIP "rep2nic2" PRIORITY 1;
Example of using the NetworkOperation clause with multiple subscribers:
CREATE REPLICATION r ELEMENT e DATASTORE MASTER rep1 SUBSCRIBER rep2,rep3 ROUTE MASTER rep1 ON "machine1" SUBSCRIBER rep2 ON "machine2" MASTERIP "1.1.1.1" PRIORITY 1 SUBSCRIBERIP "2.2.2.2" PRIORITY 1 ROUTE MASTER Rep1 ON "machine1" SUBSCRIBER Rep3 ON "machine2" MASTERIP "3.3.3.3" PRIORITY 2 SUBSCRIBERIP "4.4.4.4";
CREATE SEQUENCE
The CREATE SEQUENCE statement creates a new sequence number generator that can subsequently be used by multiple users to generate unique integers. Use the CREATE SEQUENCE statement to define the initial value of the sequence, define the increment value, the maximum or minimum value and determine if the sequence continues to generate numbers after the minimum or maximum is reached.
Required privilege
CREATE SEQUENCE (if owner) or CREATE ANY SEQUENCE (if not owner).
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout. The BATCH clause is supported in TimesTen Scaleout only.
SQL syntax
CREATE SEQUENCE [Owner.]SequenceName [INCREMENT BY IncrementValue] [MINVALUE MinimumValue] [MAXVALUE MaximumValue] [CYCLE] [CACHE CacheValue] [START WITH StartValue] [BATCH BatchValue]
Parameters
| Parameter | Description |
|---|---|
|
|
Name of the sequence number generator. |
|
|
The incremental value between consecutive numbers. This value can be either a positive or negative integer. It cannot be 0. If the value is positive, it is an ascending sequence. If the value is negative, it is descending. The default value is 1. In a descending sequence, the range starts from |
|
|
Specifies the minimum value for the sequence. The default minimum value is 1. |
|
|
The largest possible value for an ascending sequence, or the starting value for a descending sequence. The default maximum value is (263) -1, which is the maximum of |
|
|
Indicates that the sequence number generator continues to generate numbers after it reaches the maximum or minimum value. By default, sequences do not cycle. Once the number reaches the maximum value in the ascending sequence, the sequence wraps around and generates numbers from its minimum value. For a descending sequence, when the minimum value is reached, the sequence number wraps around, beginning from the maximum value. If |
|
|
|
|
|
Specifies the first sequence number to be generated. Use this clause to start an ascending sequence at a value that is greater than the minimum value or to start a descending sequence at a value less than the maximum. The |
|
|
Valid with TimesTen Scaleout only. Configures the range of unique sequence values that are stored at each element of the grid. The default value is 10 million. |
Description
-
All parameters in the
CREATE SEQUENCEstatement must be integer values. -
If you do not specify a value in the parameters, TimesTen defaults to an ascending sequence that starts with 1, increments by 1, has the default maximum value and does not cycle.
-
Do not create a sequence with the same name as a view or materialized view.
-
Sequences with the
CYCLEattribute cannot be replicated (TimesTen Classic). -
In TimesTen Classic, in which there is a replicated environment for an active standby pair, if
DDL_REPLICATION_LEVELis 3 or greater when you executeCREATE SEQUENCEon the active database, the sequence is replicated to all databases in the replication scheme. To include the sequence in the replication scheme, setDDL_REPLICATION_ACTIONtoINCLUDE. See "Making DDL changes in an active standby pair" in the Oracle TimesTen In-Memory Database Replication Guide for more information.
Usage with TimesTen Scaleout
-
The
CREATESEQUENCEstatement creates a global object. Once you create the sequence, the sequence values are retrieved from any element of the database. -
Sequence values are unique, but across elements the values might not be returned in monotonic order. Within a single element, sequence values are in monotonic order. But over time, across elements, sequence values are not returned monotonically. However, the monotonic property is guaranteed within an element.
-
The batch value is the range of unique sequence values stored in the element. Each element has its own batch. An element will get a new batch when its local batch is consumed. There is one element that owns the sequence and is responsible for allocating batch sequence blocks to other elements.
-
For the
BATCHclause:-
Use this clause to specify the range of sequence values that are stored on each element of the grid.
-
The default is 10 million.
-
BatchValuemust be greater than or equal toCacheValue. -
The maximum value for
BatchValueis dependent on the maximum value of the signed integer for the platform.
-
-
Each element in a replica set has its own batch.
-
An element's batch sequence values are recoverable. Cache values are not recoverable.
See "Using sequences" in Oracle TimesTen In-Memory Database Scaleout User's Guide for detailed information and examples.
Using CURRVAL and NEXTVAL in TimesTen Scaleout
To refer to the SEQUENCE values in a SQL statement, use CURRVAL and NEXTVAL.
-
CURRVALreturns the value of the last call toNEXTVALif there is one in the current session, otherwise it returns an error. -
NEXTVALincrements the current sequence value by the specified increment and returns the value for each row accessed.
If you execute a single SQL statement with multiple NEXTVAL references, TimesTen only increments the sequence once, returning the same value for all occurrences of NEXTVAL. If a SQL statement contains both NEXTVAL and CURRVAL, NEXTVAL is executed first. CURRVAL and NEXTVAL have the same value in that SQL statement.
NEXTVAL and CURRVAL can be used in the following.
-
The
SelectListof aSELECTstatement, but not theSelectListof a subquery -
The
SelectListof anINSERT...SELECTstatement -
The
SETclause of anUPDATEstatement
See "Using sequences" in Oracle TimesTen In-Memory Database Scaleout User's Guide for information on the usage of CURRVAL and NEXTVAL in a grid and for examples.
Using CURRVAL and NEXTVAL in TimesTen Classic
To refer to the SEQUENCE values in a SQL statement, use CURRVAL and NEXTVAL.
-
CURRVALreturns the value of the last call toNEXTVALif there is one in the current session, otherwise it returns an error. -
NEXTVALincrements the current sequence value by the specified increment and returns the value for each row accessed.
The current value of a sequence is a connection-specific value. If there are two concurrent connections to the same database, each connection has its own CURRVAL of the same sequence set to its last NEXTVAL reference. When the maximum value is reached, SEQUENCE either wraps or issues an error statement, depending on the value of the CYCLE option of the CREATE SEQUENCE. In the case of recovery, sequences are not rolled back. It is possible that the range of values of a sequence can have gaps; however, each sequence value is still unique.
If you execute a single SQL statement with multiple NEXTVAL references, TimesTen only increments the sequence once, returning the same value for all occurrences of NEXTVAL. If a SQL statement contains both NEXTVAL and CURRVAL, NEXTVAL is executed first. CURRVAL and NEXTVAL have the same value in that SQL statement.
Note:
NEXTVAL cannot be used in a query on a standby node of an active standby pair.
NEXTVAL and CURRVAL can be used in the following.
-
The
SelectListof aSELECTstatement, but not theSelectListof a subquery -
The
SelectListof anINSERT...SELECTstatement -
The
SETclause of anUPDATEstatement
Examples: TimesTen Scaleout
For detailed examples, see "Using sequences" in the Oracle TimesTen In-Memory Database Scaleout User's Guide.
Syntax example:
Command> CREATE SEQUENCE mysequence BATCH 100; Command> describe mysequence; Sequence SAMPLEUSER.MYSEQUENCE: Minimum Value: 1 Maximum Value: 9223372036854775807 Current Value: 1 Increment: 1 Cache: 20 Cycle: Off Batch: 100 1 sequence found.
Examples: TimesTen Classic
Create a sequence.
CREATE SEQUENCE mysequence INCREMENT BY 1 MINVALUE 2 MAXVALUE 1000;
This example assumes that tab1 has 1 row in the table and that CYCLE is used:
CREATE SEQUENCE s1 MINVALUE 2 MAXVALUE 4 CYCLE; SELECT s1.NEXTVAL FROM tab1; /* Returns the value of 2; */ SELECT s1.NEXTVAL FROM tab1; /* Returns the value of 3; */ SELECT s1.NEXTVAL FROM tab1; /* Returns the value of 4; */
After the maximum value is reached, the cycle starts from the minimum value for an ascending sequence.
SELECT s1.NEXTVAL FROM tab1; /* Returns the value of 2; */
To create a sequence and generate a sequence number:
CREATE SEQUENCE seq INCREMENT BY 1; INSERT INTO student VALUES (seq.NEXTVAL, 'Sally');
To use a sequence in an UPDATE SET clause:
UPDATE student SET studentno = seq.NEXTVAL WHERE name = 'Sally';
To use a sequence in a query:
SELECT seq.CURRVAL FROM student;
See also
CREATE SYNONYM
The CREATE SYNONYM statement creates a public or private synonym for a database object. A synonym is an alias for a database object. The object can be a table, view, synonym, sequence, PL/SQL stored procedure, PL/SQL function, PL/SQL package, materialized view or cache group.
A private synonym is owned by a specific user and exists in that user's schema. A private synonym is accessible to users other than the owner only if those users have appropriate privileges on the underlying object and specify the schema along with the synonym name.
A public synonym is accessible to all users as long as the user has appropriate privileges on the underlying object.
CREATE SYNONYM is a DDL statement.
Synonyms can be used in these SQL statements:
-
DML statements:
SELECT,DELETE,INSERT,UPDATE,MERGE -
Some DDL statements:
GRANT,REVOKE,CREATE TABLE ... AS SELECT,CREATE VIEW ... AS SELECT,CREATE INDEX,DROP INDEX -
Some cache group statements:
LOAD CACHE GROUP,UNLOAD CACHE GROUP,REFRESH CACHE GROUP,FLUSH CACHE GROUP
Required privilege
CREATE SYNONYM (if owner) or CREATE ANY SYNONYM (if not owner) to create a private synonym.
CREATE PUBLIC SYNONYM to create a public synonym.
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
CREATE [OR REPLACE] [PUBLIC] SYNONYM [Owner1.]synonym FOR [Owner2.]object
Parameters
| Parameter | Description |
|---|---|
|
|
Specify |
|
|
Specify When resolving references to an object, TimesTen uses a public synonym only if the object is not prefaced by a schema name. |
|
|
Specify the owner of the synonym. You cannot specify an owner if you have specified Specify the name for the synonym, which is limited to 30 bytes. |
|
|
Specify the owner in which the object resides. Specify the object name for which you are creating a synonym. If you do not qualify |
Description
-
The schema object does not need to exist when its synonym is created.
-
Do not create a public synonym with the same name as a TimesTen built-in procedure.
-
In order to use the synonym, appropriate privileges must be granted to a user for the object aliased by the synonym before using the synonym.
-
A private synonym cannot have the same name as tables, views, sequences, PLSQL packages, functions, procedures, and cache groups that are in the same schema as the private synonym.
-
A public synonym may have the same name as a private synonym or an object name.
-
If the
PassThroughattribute is set so that a query needs to executed in the Oracle database, the query is sent to the Oracle database without any changes. If the query uses a synonym for a table in a cache group, then a synonym with the same name must be defined for the corresponding Oracle database table for the query to be successful. -
When an object name is used in the DML and DDL statements in which a synonym can be used, the object name is resolved as follows:
-
Search for a match within the current schema. If no match is found, then:
-
Search for a match with a public synonym name. If no match is found, then:
-
Search for a match in the SYS schema. If no match is found, then:
-
The object does not exist.
TimesTen creates a public synonym for some objects in the
SYSschema. The name of the public synonym is the same as the object name. Thus steps 2 and 3 in the object name resolution can be switched without changing the results of the search. -
-
In a replicated environment for an active standby pair, if
DDL_REPLICATION_LEVELis 2 or greater when you executeCREATE SYNONYMon the active database, the synonym is replicated to all databases in the replication scheme. See "Making DDL changes in an active standby pair" in the Oracle TimesTen In-Memory Database Replication Guide for more information.
Examples
As user ttuser, create a synonym for the jobs table. Verify that you can retrieve the information using the synonym. Display the contents of the SYS.USER_SYNONYMS system view.
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.
Create a public synonym for the employees table.
Command> CREATE PUBLIC SYNONYM pubemp FOR employees; Synonym created.
Verify that pubemp is listed as a public synonym in the SYS.ALL_SYNONYMS system view.
Command> SELECT * FROM sys.all_synonyms; < PUBLIC, TABLES, SYS, TABLES, <NULL> > ... < TTUSER, SYNJOBS, TTUSER, JOBS, <NULL> > < PUBLIC, PUBEMP, TTUSER, EMPLOYEES, <NULL> > 57 rows found.
Create a synonym for the tab table in the terry schema. Describe the synonym.
Command> CREATE SYNONYM syntab FOR terry.tab;
Synonym created.
Command> DESCRIBE syntab;
Synonym TTUSER.SYNTAB:
For Table TERRY.TAB
Columns:
COL1 VARCHAR2 (10) INLINE
COL2 VARCHAR2 (10) INLINE
1 Synonyms found.
Redefine the synjobs synonym to be an alias for the employees table by using the OR REPLACE clause. Describe synjobs.
Command> CREATE OR REPLACE synjobs FOR employees;
Synonym created.
Command> DESCRIBE synjobs;
Synonym TTUSER.SYNJOBS:
For Table TTUSER.EMPLOYEES
Columns:
*EMPLOYEE_ID NUMBER (6) NOT NULL
FIRST_NAME VARCHAR2 (20) INLINE
LAST_NAME VARCHAR2 (25) INLINE NOT NULL
EMAIL VARCHAR2 (25) INLINE UNIQUE NOT NULL
PHONE_NUMBER VARCHAR2 (20) INLINE
HIRE_DATE DATE NOT NULL
JOB_ID VARCHAR2 (10) INLINE NOT NULL
SALARY NUMBER (8,2)
COMMISSION_PCT NUMBER (2,2)
MANAGER_ID NUMBER (6)
DEPARTMENT_ID NUMBER (4)
1 Synonyms found.See also
CREATE TABLE
The CREATE TABLE statement defines a table.
The CREATE TABLE statement is supported in TimesTen Scaleout and in TimesTen Classic. However, there are differences in syntax and semantics. For simplicity, the supported syntax, parameters, description (semantics), and examples for TimesTen Scaleout and for TimesTen Classic are separated into the usage with TimesTen Scaleout and the usage with TimesTen Classic. While there is repetition in the usages, it is presented this way in order to allow you to progress from syntax to parameters to semantics to examples for each usage.
Review the required privilege section and then see:
Required privilege
CREATE TABLE (if owner) or CREATE ANY TABLE (if not owner).
The owner of the created table must have the REFERENCES privilege on tables referenced by the REFERENCE clause.
In TimesTen Classic:
-
ADMINprivilege is required if replicating a new table across an active standby pair whenDDL_REPLICATION_LEVEL=2or greater andDDL_REPLICATION_ACTION=INCLUDE. -
These attributes cause the
CREATE TABLEto implicitly execute anALTER ACTIVE STANDBY PAIR...INCLUDE TABLEstatement. See "ALTER SESSION" for more details.
After reviewing this section, see:
CREATE TABLE: Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout. Column-based compression and aging are not supported. The using index clause and the distribution clause is not supported for global temporary tables.
See:
CREATE TABLE: Usage with TimesTen Classic
See:
SQL syntax for CREATE TABLE: TimesTen Scaleout
The syntax for a persistent table:
CREATE TABLE [Owner.]TableName ( ColumnDefinition [,...] [PRIMARY KEY (ColumnName [,...]) [UsingIndexClause1]]| [[CONSTRAINT ForeignKeyName] FOREIGN KEY ([ColumnName] [,...]) REFERENCES RefTableName [(ColumnName [,...])] [ON DELETE CASCADE]] [...] ) [UNIQUE HASH ON (HashColumnName [,...]) PAGES = PrimaryPages] [DistributionClause] [AS SelectQuery]
The syntax for the UsingIndexClause1 is shown below. Note: The CreateIndexStmt is the TimesTen CREATE INDEX statement. See "CREATE INDEX" for details. You must create a unique index as this is a requirement for a primary key.
UsingIndexClause1::= USING INDEX {GLOBAL | LOCAL}| USING INDEX (CreateIndexStmt)DistributionClause:DistributionClause::= DISTRIBUTE BY HASH [(ColumnName [,...])] | DISTRIBUTE BY REFERENCE [(ForeignKeyConstraint)] | DUPLICATE
Note:
You cannot specify aPRIMARY KEY in both the ColumnDefinition clause and the PRIMARY KEY clause. If you are specifying the UsingIndexClause1 clause, you must specify PRIMARY KEY and PRIMARY KEY must be specified after the ColumnDefinition clause. The UsingIndexClause1 clause cannot be specified as part of the ColumnDefinition clause.
Syntax for global temporary table:
The UsingIndexClause1 and the DistributionClause are not supported for global temporary tables. The syntax is:
CREATE GLOBAL TEMPORARY TABLE [Owner.]TableName ( {{ColumnDefinition} [,...] [PRIMARY KEY (ColumnName [,...])] | [[CONSTRAINT ForeignKeyName] FOREIGN KEY ([ColumnName] [,...]) REFERENCES RefTableName [(ColumnName [,...])] [ON DELETE CASCADE]] [...] } ) [UNIQUE HASH ON (HashColumnName [,...]) PAGES = PrimaryPages] [ON COMMIT { DELETE | PRESERVE } ROWS ]
Parameters for CREATE TABLE: TimesTen Scaleout
| Parameter | Description |
|---|---|
|
|
|
|
|
If you specify the |
|
|
The placement of the |
[UsingIndexClause1] |
UsingIndexClause1 is optional and is described in the next two rows of this table. You cannot specify two USING INDEX clauses in the CREATE TABLE definition. This clause enables you to define a global or local index for the PRIMARY KEY.
|
USING INDEX {GLOBAL|LOCAL} |
Part of [UsingIndexClause1]. If specified, indicates if a global or local index is to be created for the primary key.
|
USING INDEX (CreateIndexStmt) |
Part of the [UsingIndexClause1] clause. When this USING INDEX clause is specified, the (CreateIndexStmt) clause indicates that you want to define the index according to the TimesTen CREATE INDEX statement. The parentheses ( ) are required. You must create a unique index as that is the requirement for a primary key.
|
|
|
Specifies an optional user-defined name for a foreign key. If not provided by the user, the system provides a default name. |
|
|
This specifies a foreign key constraint between the new table and the referenced table identified by Columns in the first list are columns of the new table and are called the referencing columns. Columns in the second list are columns of the referenced table and are called referenced columns. These two lists must match in data type, including length, precision and scale. The referenced table must already have a primary key or unique index on the referenced column. The column name list of referenced columns is optional. If omitted, the primary index of The declaration of a foreign key creates a range index on the referencing columns. The user cannot drop the referenced table or its referenced index until the referencing table is dropped. The foreign key constraint asserts that each row in the new table must match a row in the referenced table such that the contents of the referencing columns are equal to the contents of the referenced columns. Any TimesTen supports SQL-92 A foreign key can be defined on a global temporary table, but it can only reference a global temporary table. If a parent table is defined with A foreign key cannot reference an active parent table. An active parent table is one that has some instance materialized for a connection. If you specify the |
|
|
Enables the |
|
|
Hash index for the table. |
|
|
Column defined in the table that is to participate in the hash key of this table. The columns specified in the hash index must be identical to the columns in the primary key. If you specify the |
|
|
Sizes the hash index to reflect the expected number of pages in your table. To determine the value for The value for If your estimate for |
|
|
The optional statement specifies whether to delete or preserve rows when a transaction that touches a global temporary table is committed. If not specified, the rows of the temporary table are deleted. |
|
|
If specified, creates a new table from the contents of the result set of the Data types and data type lengths are derived from
You can specify a statement level optimizer hint after the |
|
|
Supported in TimesTen Scaleout only. There are three options:
The The The If you do not specify a clause, the default is You must specify the You cannot update the distribution key columns. |
|
|
Specifies that the table being created is a global temporary table. A temporary table is similar to a persistent table but it is effectively materialized only when referenced in a connection. A global temporary table definition is persistent and is visible to all connections, but the table instance is local to each connection. It is created when a command referencing the table is compiled for a connection and dropped when the connection is disconnected. All instances of the same temporary table have the same name but they are identified by an additional connection ID together with the table name. Global temporary tables are allocated in temp space. The contents of a global temporary table cannot be shared between connections. Each connection sees only its own content of the table and compiled commands that reference temporary tables are not shared among connections. Operations on temporary tables do generate log records. The amount of log they generate is less than for permanent tables. The
Local temporary tables are not supported. No object privileges are needed to access global temporary tables. Do not specify the |
|
|
Name of the column in a table. If the name is used in the primary key definition, it forms the primary key for the table to be created. Up to 16 columns can be specified for the primary key. For a foreign key, the If you specify the |
Column definition: TimesTen Scaleout
SQL syntax
You can only use the keyword, ENABLE, when defining columns in the CREATE TABLE statement.
The syntax is as follows:
ColumnName ColumnDataType [DEFAULT DefaultVal] [[NOT] INLINE] [PRIMARY KEY | UNIQUE | NULL [UNIQUE] | NOT NULL [ENABLE] [PRIMARY KEY | UNIQUE] ]
Column definition parameters
The column definition has the following parameters:
| Parameter | Description |
|---|---|
|
|
Name to be assigned to one of the columns in the new table. No two columns in the table can be given the same name. A table can have a maximum of 1000 columns. If you specify the |
|
|
Type of data the column can contain. Some data types require that you indicate a length. See Data Types for the data types that can be specified. If you specify the |
|
|
Indicates that if a value is not specified for the column in an The following are the supported data types for
If the default value is one of the users, the data type of the column must be either If you specify the |
|
|
By default, variable-length columns whose declared column length is greater than 128 bytes are stored out of line. Variable-length columns whose declared column length is less than or equal to 128 bytes are stored inline. The default behavior can be overridden during table creation through the use of the If you specify the |
|
|
Indicates that the column can contain If you specify the If you specify |
|
|
Indicates that the column cannot contain If you specify the If you specify You can only use the keyword, |
|
|
A unique constraint placed on the column. No two rows in the table may have the same value for this column. TimesTen creates a unique range index to enforce uniqueness. So a column with a unique constraint can use more memory and time during execution than a column without the constraint. Cannot be used with If you specify the |
|
|
A unique If you specify the |
Description for USING INDEX clauses in CREATE TABLE: TimesTen Scaleout
PRIMARY KEY clause in your CREATE TABLE definition. This clause enables you to specify a global or local index for the primary key constraint.
-
The
USINGINDEX {GLOBAL | LOCAL}clause is one option that enables you to specify a global or local index for the primary key constraint. You must specify theGLOBALor theLOCALkeyword. You can optionally specify theUSEHASHINDEXclause after theUSINGINDEX {GLOBAL | LOCAL}clause if you want to define a hash index. - The
USING INDEX (CreateIndexStmt)clause is your other option for specifying a global or local index. The(CreateIndexStmt)clause indicates that you want to define the index according to the TimesTenCREATEINDEXstatement. The parentheses( )are required. You must create a unique index as that is the requirement for a primary key constraint. If you use theCREATEINDEXstatement to create a hash index, see "CREATE INDEX" for information on theCREATEINDEXstatement.
Note:
You cannot use both theUSING INDEX {GLOBAL | LOCAL} and the USING INDEX (CreateIndexStmt) in the CREATE TABLE definition. Specify one clause or the other or specify neither.
PAGES= clause for this purpose. Consider these options:
-
If you specify the
USINGINDEX...CreateIndexStmtclause to create aHASHindex, you have the option of specifying thePAGES=clause. If you do not specify thePAGES=clause, TimesTen usesPAGES=CURRENTas the default to size the hash index. (See "CREATE INDEX" for details on theCREATEINDEXstatement.) -
If you specify the
UNIQUEHASHONclause (part of theCREATETABLEdefinition), you must specify thePAGES=clause to size the hash index. -
If you specify both the
USINGINDEX...CreateIndexStmtand theUNIQUEHASHONclause (part of theCREATETABLEdefinition), TimesTen uses the value specified in theUNIQUE HASH ON...PAGES=clause to size the hash index. TimesTen also issues a warning that there was a different number of pages specified for the hash index and it is using the value specified in theUNIQUE HASH ON...PAGES=clause.
PAGES= clause is specified in both the CreateIndexStmt clause (PAGES=200) and the UNIQUE HASH ON clause (PAGES=400). TimesTen issues a warning and uses PAGES=400 to size the hash index:Command> CREATE TABLE mytab (col1 TT_INTEGER, col2 TT_INTEGER, PRIMARY KEY (col1, col2)
USING INDEX (CREATE GLOBAL UNIQUE HASH INDEX myindex on mytab (col1,col2) PAGES=200))
UNIQUE HASH ON (col1,col2) PAGES=400 DISTRIBUTE BY HASH (col1);
Warning 2252: Different number of pages specified for hash index MYINDEX in table and index definition.
Index created with pages = 400
-
The
USINGINDEXclause cannot be used for foreign key constraints on a table. -
The
USINGINDEXclause cannot be used with views.
See "CREATE INDEX" for information on global and local indexes and their use in TimesTen Scaleout.
Additional information for CREATE TABLE: TimesTen Scaleout
-
TimesTen Scaleout distributes data by one of three distribution schemes:
-
Hash: TimesTen Scaleout distributes data based on the hash of the primary key column(s) or one or more columns you specify in the
DISTRIBUTEDBYHASHclause. A given row is stored in a replica set. Rows are evenly distributed across the replica sets. Hash is the default distribution scheme as it is appropriate for most tables. -
Reference: TimesTen Scaleout distributes data of a child table based on the location of the parent table that is identified by the foreign key. A given row of a child table is present in the same replica set as its parent table. This distribution scheme optimizes joins by distributing related data within a single replica set. You can distribute the parent table by hash or reference. The parent is called the root table if it is distributed by hash. You must define the child (foreign) key columns as
NOTNULL. -
Duplicate: TimesTen Scaleout distributes full identical copies of data to all elements of the database. All rows are present in all elements. This distribution scheme optimizes the performance of reads by storing identical data in every data instance. This distribution scheme is appropriate for tables that are relatively small, frequently read, and infrequently modified.
See "Defining the distribution scheme for tables" and "Defining table distribution schemes" in the Oracle TimesTen In-Memory Database Scaleout User's Guide for more information.
-
-
For tables with a hash distribution scheme:
-
The distribution key is used if specified.
-
The primary key is used if the distribution key is not specified.
-
A hidden column is used if there is no primary key or distribution key. Data is distributed randomly and evenly.
You should specify a distribution key if there is a primary key defined on the table, but the primary key is not the best way to distribute the data. If there is no primary key, but there is a unique column, then you may want to distribute the data on this unique column. If there is no primary key and no unique column, then do not specify a distribution key. TimesTen Scaleout distributes the data on the hidden column.
-
-
If the distribution scheme is by reference:
-
Only a single foreign key constraint can be referenced in the
DISTRIBUTEBYREFERENCEclause. There may be multiple foreign key constraints in the child table, but only one can be used to determine the reference distribution. -
A referenced foreign key constraint must be named in the constraint clause if there is more than one.
-
The foreign key constraint in the reference distribution clause must reference the primary key or a unique key of the parent table. If the parent table is the root, the referenced key must be the distribution key.
-
You can create a foreign key relationship to a non distribution key column of the parent table, but you cannot then distribute by reference based on this foreign key relationship.
-
You cannot update the foreign key column that is used in the
DISTRIBUTEBYREFERENCEclause.
-
- If you are planning to load your tables with data, consider creating your tables without indexes. After the data is loaded, you can then create your indexes. This reduces the time it take to load the data into the tables. The exception is if you are using foreign keys and reference tables.
-
You can use the
CREATETABLE...ASSELECTstatement to create a new table based on the definition of the original table. Note that primary key constraints are not carried over to the new table so how the data is distributed changes if you do not define a primary key constraint on the new table.See "Use CREATE TABLE...AS SELECT" for more information.
-
You cannot update the distribution key column(s) unless you update the column(s) to the same value.
-
All columns participating in the primary key are
NOT NULL. -
A
PRIMARY KEYthat is specified in theColumnDefinitioncan only be specified for one column. -
You cannot specify a
PRIMARYKEYin both theColumnDefinitionclause and thePRIMARYKEYclause. -
For both primary key and foreign key constraints, duplicate column names are not allowed in the constraint column list.
-
You cannot update primary key column(s) unless you update the column(s) to the same value.
-
There are performance considerations when you define out of line columns instead of inline columns:
-
Accessing data is slower because TimesTen does not store data contiguously with out of line columns.
-
Populating data is slower because TimesTen generates more logging operations.
-
Deleting data is slower because TimesTen performs more reclaim and logging operations.
-
Storing a column requires less overhead.
-
-
If
ON DELETE CASCADEis specified on a foreign key constraint for a child table, a user can delete rows from a parent table for which the user has theDELETEprivilege without requiring explicitDELETEprivilege on the child table. -
To change the
ON DELETE CASCADEtriggered action, drop then redefine the foreign key constraint. -
You cannot create a table that has a foreign key referencing a cached table.
-
UNIQUEcolumn constraint and default column values are not supported with materialized views. -
Use the
ALTER TABLEstatement to change the representation of the primary key index for a table. -
If you specify the
ASSelectQueryclause:-
Data types and data type lengths are derived from the
SelectQuery. Do not specify data types on the columns of the table you are creating. -
TimesTen defines on columns in the new table
NOT NULLconstraints that were explicitly created on the corresponding columns of the selected table ifSelectQueryselects the column rather than an expression containing the column. -
NOT NULLconstraints that were implicitly created by TimesTen on columns of the selected table (for example, primary keys) are carried over to the new table. You can override theNOT NULLconstraint on the selected table by defining the new column asNULL. For example:CREATE TABLE newtable (newcol NULL) AS SELECT (col) FROM tab;
-
NOT INLINE/INLINEattributes are carried over to the new table. -
Unique keys, foreign keys, indexes and column default values are not carried over to the new table.
-
If all expressions in
SelectQueryare columns, rather than expressions, then you can omit the columns from the table you are creating. In this case, the name of the columns are the same as the columns inSelectQuery. If theSelectQuerycontains an expression rather than a simple column reference, either specify a column alias or name the column in theCREATE TABLEstatement. -
Do not specify foreign keys on the table you are creating.
-
Do not specify the
SELECT FOR UPDATEclause inSelectQuery. -
The
ORDER BYclause is not supported when you use theASSelectQueryclause. -
SelectQuerycannot contain set operatorsUNION,MINUS,INTERSECT.
-
-
By default, a range index is created to enforce the primary key. Use the
UNIQUE HASHclause to specify a hash index for the primary key.-
If your application performs range queries using a table's primary key, then choose a range index for that table by omitting the
UNIQUE HASHclause. -
If your application performs only exact match lookups on the primary key, then a hash index may offer better response time and throughput. In such a case, specify the
UNIQUE HASHclause.
-
-
A hash index is created with a fixed size that remains constant for the life of the table or until the hash index is resized with the
ALTER TABLEstatement or when the index is dropped and recreated. A smaller hash index results in more hash collisions. A larger hash index reduces collisions but can waste memory. Hash key comparison is a fast operation, so a small number of hash collisions should not cause a performance problem for TimesTen.To ensure that your hash index is sized correctly, your application must indicate the expected size of your table with the value of the
RowPagesparameter of theSETPAGESclause. Compute this value by dividing the number of expected rows in your table by 256. For example, if your table has 256,000 rows, specify 1000 for the value of RowPages (256000/256=1000). -
At most 16 columns are allowed in a hash key.
-
ON DELETE CASCADEis supported on detail tables of a materialized view. If you have a materialized view defined over a child table, a deletion from the parent table causes cascaded deletes in the child table. This, in turn, triggers changes in the materialized view. -
The total number of rows reported by the
DELETEstatement does not include rows deleted from child tables as a result of theON DELETE CASCADEaction. -
For
ON DELETE CASCADE: Since different paths may lead from a parent table to a child table, the following rule is enforced:-
Either all paths from a parent table to a child table are "delete" paths or all paths from a parent table to a child table are "do not delete" paths. Specify
ON DELETE CASCADEon all child tables on the "delete" path. -
This rule does not apply to paths from one parent to different children or from different parents to the same child.
-
-
For
ON DELETE CASCADE, the following rule is also enforced.-
If a table is reached by a "delete" path, then all its children are also reached by a "delete" path.
-
-
The data in a global temporary table is private to the current connection and does not need to be secured between users. Thus, global temporary tables do not require object privileges.
Examples: Global and local indexes in TimesTen Scaleout
These examples show various uses of the syntax for using global indexes with CREATE TABLE...PRIMARY KEY.
USING INDEX GLOBAL clause to create a global range index. The index must be unique as is a requirement for a primary key.Command> CREATE TABLE mytab (c TT_INTEGER, b TT_INTEGER, a TT_INTEGER,
PRIMARY KEY (c,b) USING INDEX GLOBAL) DISTRIBUTE BY HASH (a,b);
Command> indexes mytab;
Indexes on table SAMPLEUSER.MYTAB:
MYTAB: global unique range index on columns:
C
B
1 index found.
1 index found on 1 table
Command> DROP TABLE mytab;Create a table specifying a primary key. Use the USING INDEX LOCAL clause to create a local range index. The index must be unique as is a requirement for a primary key.
Command> CREATE TABLE mytab (c TT_INTEGER, b TT_INTEGER, a TT_INTEGER,
PRIMARY KEY (c,b) USING INDEX LOCAL DISTRIBUTE BY HASH (a,b);
Command> indexes mytab;
Indexes on table SAMPLEUSER.MYTAB:
MYTAB: unique range index on columns:
C
B
1 index found.
1 index found on 1 table.
Command> DROP TABLE mytab;Create a table specifying a primary key. Use the USING INDEX (CreateIndexStmt) clause to create a global range index. The (CreateIndexStmt) clause indicates that you want to define the index according to the TimesTen CREATE INDEX statement. The parentheses ( ) are required. You must specify the UNIQUE keyword when creating the index. This is a requirement for a primary key. See "CREATE INDEX" for information on this statement.
Command> CREATE TABLE mytab (c TT_INTEGER, b TT_INTEGER, a TT_INTEGER,
PRIMARY KEY (c,b) USING INDEX (CREATE GLOBAL UNIQUE INDEX GlobalUniqueIdx ON mytab (c,b))) DISTRIBUTE BY HASH (a,b);
Command> indexes mytab;
Indexes on table SAMPLEUSER.MYTAB:
GLOBALUNIQUEIDX: global unique range index on columns:
C
B
1 index found.
1 index found on 1 table.
Command> DROP TABLE mytab;Create a table specifying a primary key. Use the USING INDEX (CreateIndexStmt) clause to create a global range index. The (CreateIndexStmt) clause indicates that you want to define the index according to the TimesTen CREATE INDEX statement. The parentheses ( ) are required. The CREATE INDEX definition specifies the INCLUDE clause to include additional column(s) in the index definition. You must specify the UNIQUE keyword when creating the index. This is a requirement for a primary key. See "CREATE INDEX" for information on this statement.
Command> CREATE TABLE mytab (c TT_INTEGER, b TT_INTEGER, a TT_INTEGER,
PRIMARY KEY (c,b) USING INDEX (CREATE GLOBAL UNIQUE INDEX GlobalUniqueIdx
ON mytab (c,b) INCLUDE (a))) DISTRIBUTE BY HASH (a,b);
Command> indexes mytab;
Indexes on table SAMPLEUSER.MYTAB:
GLOBALUNIQUEIDX: global unique range index on columns:
C
B
Included columns:
A
1 index found.
1 index found on 1 table.
Command> DROP TABLE mytab;Create a table specifying a primary key. Use the USING INDEX (CreateIndexStmt) clause to create a global unique hash index. The (CreateIndexStmt) clause indicates that you want to define the index according to the TimesTen CREATE INDEX statement. The parentheses ( ) are required. You must specify the UNIQUE keyword when creating the index. This is a requirement for a primary key. See "CREATE INDEX" for information on this statement.
Command> CREATE TABLE mytab (c TT_INTEGER, b TT_INTEGER, a TT_INTEGER,
PRIMARY KEY (c,b) USING INDEX (CREATE GLOBAL UNIQUE HASH INDEX GlobalUniqueIdx
ON mytab (c,b))) DISTRIBUTE BY HASH (a,b);
Command> indexes mytab;
Indexes on table SAMPLEUSER.MYTAB:
GLOBALUNIQUEIDX: global unique hash index on columns:
C
B
1 index found.
1 index found on 1 table.
Command> DROP TABLE mytab;Additional examples: TimesTen Scaleout
These examples illustrate how to create tables with the duplicate, hash, and reference distribution schemes.
These examples illustrate how to create tables with the DISTRIBUTE BY REFERENCE distribution scheme:
"Use CREATE TABLE...AS SELECT" shows how to use the CREATE TABLE...AS SELECT clause in TimesTen Scaleout.
Create the account_type table
This example runs ttIsql to create the account_type table and use a duplicate distribution scheme to distribute the data. This table contains few rows and uses a duplicate distribution scheme to optimize reads. Copies of the data in the table are distributed to all elements of the database.
Command> CREATE TABLE account_type ( type CHAR(1) NOT NULL PRIMARY KEY,
description VARCHAR2(100) NOT NULL) DUPLICATE;Create the account_status table
This example runs ttIsql to create the account_status table and use a duplicate distribution scheme. The table size is small and uses a distribution scheme to optimize reads. Copies of the data in the table are distributed to all elements of the database.
Command> CREATE TABLE account_status(status NUMBER(2) NOT NULL PRIMARY KEY,
description VARCHAR2(100) NOT NULL) DUPLICATE;Create the customers table
This example runs ttIsql to create the customers table and distributes the table by hash. The data in the table is distributed to each element based on the hash of the cust_id column (the primary key).
Command> CREATE TABLE customers(cust_id NUMBER(10,0) NOT NULL PRIMARY KEY,
first_name VARCHAR2(30) NOT NULL,last_name VARCHAR2(30) NOT NULL,
addr1 VARCHAR2(64),addr2 VARCHAR2(64), zipcode VARCHAR2(5),
member_since DATE NOT NULL)
DISTRIBUTE BY HASH;Create the accounts table
This example runs ttIsql to create the accounts table and defines three primary/foreign key relationships. The accounts table is distributed by reference and the data is distributed based on the fk_customer foreign key constraint. This scheme optimizes the performance of joins by distributing the data in the accounts table based on the location of the corresponding value of the customers.cust_id parent column (of the fk_customer foreign key constraint). The row of a child table exists in the same replica set as the parent table. If the join is performed on the primary or foreign key, the data is stored on one element, so TimesTen Scaleout does not have to access different elements.
Command> CREATE TABLE accounts(account_id NUMBER(10,0) NOT NULL PRIMARY KEY,
phone VARCHAR2(15) NOT NULL,account_type CHAR(1) NOT NULL,
status NUMBER(2) NOT NULL,current_balance NUMBER(10,2) NOT NULL,
prev_balance NUMBER(10,2) NOT NULL,date_created DATE NOT NULL,
cust_id NUMBER(10,0) NOT NULL,
CONSTRAINT fk_customer FOREIGN KEY (cust_id)
REFERENCES customers(cust_id),CONSTRAINT fk_acct_type
FOREIGN KEY (account_type)
REFERENCES account_type(type),
CONSTRAINT fk_acct_status
FOREIGN KEY (status)
REFERENCES account_status(status)
)
DISTRIBUTE BY REFERENCE (fk_customer);Create the transactions table
This example runs ttIsql to create the transactions table. The transactions table is distributed by reference and the data is distributed based on the fk_accounts foreign key constraint. This scheme optimizes the performance of joins by distributing the data in the transaction table based on the location of the corresponding value of the accounts.account_id parent column (of the fk_accounts foreign key constraint). The row of a child table exists in the same replica set as the parent table. If the join is performed on the primary or foreign key, the data is stored on one element, so TimesTen Scaleout does not have to access different elements.
The accounts parent table is also distributed by reference. This defines a two level distribute by reference distribution hierarchy.
Command> CREATE TABLE transactions(transaction_id NUMBER(10,0) NOT NULL,
account_id NUMBER(10,0) NOT NULL ,
transaction_ts TIMESTAMP NOT NULL,
description VARCHAR2(60),
optype CHAR(1) NOT NULL,
amount NUMBER(6,2) NOT NULL,
PRIMARY KEY (account_id, transaction_id, transaction_ts),
CONSTRAINT fk_accounts FOREIGN KEY (account_id)
REFERENCES accounts(account_id)
)
DISTRIBUTE BY REFERENCE (fk_accounts);View the tables
This example runs the ttIsql tables command to view the tables in the database.
Command> tables; SAMPLEUSER.ACCOUNTS SAMPLEUSER.ACCOUNT_STATUS SAMPLEUSER.ACCOUNT_TYPE SAMPLEUSER.CUSTOMERS SAMPLEUSER.TRANSACTIONS 5 tables found.
View the definition of the accounts table
This example runs the ttIsql describe command to view the definition of the accounts table.
Command> describe accounts;
Table SAMPLEUSER.ACCOUNTS:
Columns:
*ACCOUNT_ID NUMBER (10) NOT NULL
PHONE VARCHAR2 (15) INLINE NOT NULL
ACCOUNT_TYPE CHAR (1) NOT NULL
STATUS NUMBER (2) NOT NULL
CURRENT_BALANCE NUMBER (10,2) NOT NULL
PREV_BALANCE NUMBER (10,2) NOT NULL
DATE_CREATED DATE NOT NULL
CUST_ID NUMBER (10) NOT NULL
DISTRIBUTE BY REFERENCE (FK_CUSTOMER)
1 table found.
(primary key columns are indicated with *)DISTRIBUTE BY REFERENCE with one foreign key
This example illustrates that you do not have to specify the foreign key constraint in the DISTRIBUTE BY REFERENCE clause. There is only one foreign key.
First create the Orders table and distribute by hash.
Command> CREATE TABLE Orders
(OrderId TT_INTEGER NOT NULL PRIMARY KEY,
OrderDate DATE NOT NULL,
discount BINARY_FLOAT)
DISTRIBUTE BY HASH;
Create the OrderDetails table with one foreign key constraint. There is no need to name the constraint in the distribution clause.
Command> CREATE TABLE OrderDetails
(OrderId TT_INTEGER NOT NULL,
PartId TT_INTEGER NOT NULL,
Quantity TT_INTEGER NOT NULL,
FOREIGN KEY (OrderId)
REFERENCES Orders (OrderId))
DISTRIBUTE BY REFERENCE;
Run the ttIsql describe command to view the tables.
Command> describe Orders;
Table SAMPLEUSER.ORDERS:
Columns:
*ORDERID TT_INTEGER NOT NULL
ORDERDATE DATE NOT NULL
DISCOUNT BINARY_FLOAT
DISTRIBUTE BY HASH (ORDERID)
1 table found.
(primary key columns are indicated with *)
Command> describe OrderDetails;
Table SAMPLEUSER.ORDERDETAILS:
Columns:
ORDERID TT_INTEGER NOT NULL
PARTID TT_INTEGER NOT NULL
QUANTITY TT_INTEGER NOT NULL
DISTRIBUTE BY REFERENCE
1 table found.
(primary key columns are indicated with *)Table with more than one foreign key
This example illustrates that if a table contains more than one foreign key constraint, the DISTRIBUTE BY REFERENCE clause must name the foreign key constraint that will be used as the reference. The customers2 table is the parent and is distributed by hash. The OrderDetails2 table contains two foreign key constraints and this table is distributed by reference on the c1_1 constraint. This constraint must be included in the DISTRIBUTED BY REFERENCE clause.
Command> CREATE TABLE customers2 (CustomerId TT_INTEGER NOT NULL PRIMARY KEY,
LastOrderDate DATE NOT NULL,PromotionDiscount BINARY_FLOAT)
DISTRIBUTE BY HASH;
Command> CREATE TABLE OrderDetails2 (OrderId TT_INTEGER NOT NULL,
CustomerId TT_INTEGER NOT NULL, Quantity TT_INTEGER NOT NULL,
CONSTRAINT c1_1 FOREIGN KEY (OrderId)
REFERENCES Orders (OrderId),
CONSTRAINT c2_2 FOREIGN KEY (CustomerId)
REFERENCES Customers2 (CustomerId))
DISTRIBUTE BY REFERENCE (c1_1);Foreign key relationship not on distribution key of the parent table
This example creates the orders2 parent table with the OrderId primary key and the CouponId unique key. The table is distributed by hash. Since no distribution key is specified, the data is distributed by hash on the OrderId primary key. The coupons child table establishes a foreign key relationship on the CouponId unique key. Since this key is not the distribution key of the orders2 parent table, TimesTen Scaleout throws an error.
Command> CREATE TABLE Orders2 (OrderId TT_INTEGER NOT NULL PRIMARY KEY,
CouponId TT_INTEGER NOT NULL UNIQUE, OrderDate DATE NOT NULL,
discount BINARY_FLOAT)
DISTRIBUTE BY HASH;
Command> CREATE TABLE Coupons (CouponId TT_INTEGER NOT NULL,
discount BINARY_FLOAT,
CONSTRAINT CouponC1 FOREIGN KEY (CouponId)
REFERENCES Orders2 (CouponId) )
DISTRIBUTE BY REFERENCE (CouponC1);
1067: The Parent keys for a distribute by reference table with hash distributed
parent must include the distribution keys of the parent.
The command failed.Using first and second level child foreign key relationship
This example creates the Coupons2 parent table and distributes the data by hash. The Orders3 child table is created as a first level foreign key relationship and the parent table (Coupons2) is the root table. The OrderDetails3 child table is created as a second level foreign key relationship and the parent table (Orders3) is a reference table.
Command> CREATE TABLE Coupons2 (CouponId TT_INTEGER NOT NULL PRIMARY KEY,
discount BINARY_FLOAT)
DISTRIBUTE BY HASH;
Command> CREATE TABLE Orders3 (OrderId TT_INTEGER NOT NULL PRIMARY KEY,
CouponId TT_INTEGER NOT NULL, OrderDate DATE NOT NULL,
discount BINARY_FLOAT, CONSTRAINT c1_coupons FOREIGN KEY (CouponId)
REFERENCES Coupons2 (CouponId))
DISTRIBUTE BY REFERENCE (c1_coupons);
Command> CREATE TABLE OrderDetails3 (OrderId TT_INTEGER NOT NULL,
PartId TT_INTEGER NOT NULL, quantity TT_INTEGER NOT NULL,
CONSTRAINT c1_orders FOREIGN KEY (OrderId)
REFERENCES Orders3 (OrderId))
DISTRIBUTE BY REFERENCE (C1_orders);Use CREATE TABLE...AS SELECT
This example creates the NewCustomers table based on the customers table. It defines a primary key constraint to maintain the same distribution scheme and ensure the data is distributed on the primary key.
Command> CREATE TABLE NewCustomers(cust_id PRIMARY KEY, first_name, last_name,
addr1, addr2, zipcode, member_since) AS SELECT * FROM customers;
0 rows inserted.
Command> describe NewCustomers;
Table SAMPLEUSER.NEWCUSTOMERS:
Columns:
*CUST_ID NUMBER (10) NOT NULL
FIRST_NAME VARCHAR2 (30) INLINE NOT NULL
LAST_NAME VARCHAR2 (30) INLINE NOT NULL
ADDR1 VARCHAR2 (64) INLINE
ADDR2 VARCHAR2 (64) INLINE
ZIPCODE VARCHAR2 (5) INLINE
MEMBER_SINCE DATE NOT NULL
DISTRIBUTE BY HASH (CUST_ID)
1 table found.
(primary key columns are indicated with *)
Run ttIsql describe to view the original customers table:
Command> describe Customers;
Table SAMPLEUSER.CUSTOMERS:
Columns:
*CUST_ID NUMBER (10) NOT NULL
FIRST_NAME VARCHAR2 (30) INLINE NOT NULL
LAST_NAME VARCHAR2 (30) INLINE NOT NULL
ADDR1 VARCHAR2 (64) INLINE
ADDR2 VARCHAR2 (64) INLINE
ZIPCODE VARCHAR2 (5) INLINE
MEMBER_SINCE DATE NOT NULL
DISTRIBUTE BY HASH (CUST_ID)
1 table found.
(primary key columns are indicated with *)SQL syntax for CREATE TABLE: TimesTen Classic
You cannot specify a PRIMARY KEY in both the ColumnDefinition clause and the PRIMARY KEY clause.
The syntax for a persistent table:
CREATE TABLE [Owner.]TableName ( {{ColumnDefinition} [,...] [PRIMARY KEY (ColumnName [,...]) | [[CONSTRAINT ForeignKeyName] FOREIGN KEY ([ColumnName] [,...]) REFERENCES RefTableName [(ColumnName [,...])] [ON DELETE CASCADE]] [...] } ) [ColumnBasedCompression] [UNIQUE HASH ON (HashColumnName [,...]) PAGES = PrimaryPages] [AGING {LRU| USE ColumnName LIFETIME Num1 {SECOND[S] | MINUTE[S] | HOUR[S] |DAY[S]} [CYCLE Num2 {SECOND[S] | MINUTE[S] |HOUR[S] |DAY[S]}] }[ON|OFF] ] [AS SelectQuery]
The syntax for a global temporary table is:
CREATE GLOBAL TEMPORARY TABLE [Owner.]TableName ( {{ColumnDefinition} [,...] [PRIMARY KEY (ColumnName [,...]) | [[CONSTRAINT ForeignKeyName] FOREIGN KEY ([ColumnName] [,...]) REFERENCES RefTableName [(ColumnName [,...])] [ON DELETE CASCADE]] [...] } ) [UNIQUE HASH ON (HashColumnName [,...]) PAGES = PrimaryPages] [ON COMMIT { DELETE | PRESERVE } ROWS]
Parameters for CREATE TABLE: TimesTen Classic
| Parameter | Description |
|---|---|
|
|
Name to be assigned to the new table. Two tables cannot have the same owner name and table name. If you do not specify the owner name, your login name becomes the owner name for the new table. Owners of tables in TimesTen are determined by the user ID settings or login names. Oracle Database table owner names must always match TimesTen table owner names. See "Basic names" for rules on defining names. |
|
|
Specifies that the table being created is a global temporary table. A temporary table is similar to a persistent table but it is effectively materialized only when referenced in a connection. A global temporary table definition is persistent and is visible to all connections, but the table instance is local to each connection. It is created when a command referencing the table is compiled for a connection and dropped when the connection is disconnected. All instances of the same temporary table have the same name but they are identified by an additional connection ID together with the table name. Global temporary tables are allocated in temp space. The contents of a global temporary table cannot be shared between connections. Each connection sees only its own content of the table and compiled commands that reference temporary tables are not shared among connections. When Temporary tables are automatically excluded from active standby pairs or when the A cache group table cannot be defined as a temporary table. Changes to temporary tables cannot be tracked with XLA. Operations on temporary tables do generate log records. The amount of log they generate is less than for permanent tables. Truncate table is not supported with global temporary tables. Local temporary tables are not supported. No object privileges are needed to access global temporary tables. Do not specify the |
|
|
An individual column in a table. Each table must have at least one column. If you specify the |
|
|
Name of the column in a table. Is used in various clauses of the If the name is used in the primary key definition, it forms the primary key for the table to be created. Up to 16 columns can be specified for the primary key. For a foreign key, the If you specify the |
|
|
|
|
|
Specifies an optional user-defined name for a foreign key. If not provided by the user, the system provides a default name. |
|
|
This specifies a foreign key constraint between the new table and the referenced table identified by Columns in the first list are columns of the new table and are called the referencing columns. Columns in the second list are columns of the referenced table and are called referenced columns. These two lists must match in data type, including length, precision and scale. The referenced table must already have a primary key or unique index on the referenced column. The column name list of referenced columns is optional. If omitted, the primary index of The declaration of a foreign key creates a range index on the referencing columns. The user cannot drop the referenced table or its referenced index until the referencing table is dropped. The foreign key constraint asserts that each row in the new table must match a row in the referenced table such that the contents of the referencing columns are equal to the contents of the referenced columns. Any TimesTen supports SQL-92 A foreign key can be defined on a global temporary table, but it can only reference a global temporary table. If a parent table is defined with A foreign key cannot reference an active parent table. An active parent table is one that has some instance materialized for a connection. If you specify the |
|
|
Enables the |
|
|
Defines compression at the column level, which stores data more efficiently. Eliminates redundant storage of duplicate values within columns and improves the performance of SQL queries that perform full table scans. See "Column-based compression of tables (TimesTen Classic)" for details. |
|
|
|
|
|
Hash index for the table. This parameter is used for equality predicates. |
|
|
Column defined in the table that is to participate in the hash key of this table. The columns specified in the hash index must be identical to the columns in the primary key. If you specify the |
|
|
Sizes the hash index to reflect the expected number of pages in your table. To determine the value for The value for If your estimate for |
|
|
The optional statement specifies whether to delete or preserve rows when a transaction that touches a global temporary table is committed. If not specified, the rows of the temporary table are deleted. |
|
|
If specified, defines the LRU aging policy for the table. The LRU aging policy defines the type of aging (least recently used (LRU)), the aging state ( Set the aging state to either LRU attributes are defined by calling the |
|
|
If specified, defines the time-based aging policy for the table. The time-based aging policy defines the type of aging (time-based), the aging state ( Set the aging state to either Time-based aging attributes are defined at the SQL level and are specified by the Specify The values of the column that you use for aging are updated by your applications. If the value of this column is unknown for some rows, and you do not want the rows to be aged, define the column with a large default value (the column cannot be You can define your aging column with a data type of If you specify the AS For more information about time-based aging, see "Implementing an aging policy in your tables" in Oracle TimesTen In-Memory Database Operations Guide. |
|
|
Specify the The Specify The concept of time resolution is supported. If |
|
|
The Specify If you do not specify the If the aging state is |
|
|
If specified, creates a new table from the contents of the result set of the Data types and data type lengths are derived from
You can specify a statement level optimizer hint after the |
Column definition: TimesTen Classic
SQL syntax
You can only use the keyword, ENABLE, when defining columns in the CREATE TABLE statement.
For all data types other than LOBs, the syntax is as follows:
ColumnName ColumnDataType [DEFAULT DefaultVal] [[NOT] INLINE] [PRIMARY KEY | UNIQUE | NULL [UNIQUE] | NOT NULL [ENABLE] [PRIMARY KEY | UNIQUE] ]
For LOB data types, you cannot create a primary key or unique constraint on LOB columns. In addition, LOB data types are stored out of line, so the INLINE attribute cannot be specified.
LOB data types are not supported with TimesTen Scaleout.
For all LOB data types, the syntax is:
ColumnName ColumnDataType [DEFAULT DefaultVal] [[NOT] NULL [ENABLE]] | [[NOT] NULL [ENABLE]] [DEFAULT DefaultVal]
Parameters
The column definition has the following parameters:
| Parameter | Description |
|---|---|
|
|
Name to be assigned to one of the columns in the new table. No two columns in the table can be given the same name. A table can have a maximum of 1000 columns. If you specify the |
|
|
Type of data the column can contain. Some data types require that you indicate a length. See Data Types for the data types that can be specified. If you specify the |
|
|
Indicates that if a value is not specified for the column in an The following are the supported data types for
If the default value is one of the users, the data type of the column must be either If you specify the |
|
|
By default, variable-length columns whose declared column length is greater than 128 bytes are stored out of line. Variable-length columns whose declared column length is less than or equal to 128 bytes are stored inline. The default behavior can be overridden during table creation through the use of the If you specify the |
|
|
Indicates that the column can contain If you specify the If you specify |
|
|
Indicates that the column cannot contain If you specify the If you specify You can only use the keyword, |
|
|
A unique constraint placed on the column. No two rows in the table may have the same value for this column. TimesTen creates a unique range index to enforce uniqueness. So a column with a unique constraint can use more memory and time during execution than a column without the constraint. Cannot be used with If you specify the |
|
|
A unique If you specify the |
Description for CREATE TABLE: TimesTen Classic
- If you are planning to load your tables with data, consider creating your tables without indexes. After the data is loaded, you can then create your indexes. This reduces the time it take to load the data into the tables.
-
All columns participating in the primary key are
NOT NULL. -
A
PRIMARY KEYthat is specified in theColumnDefinitioncan only be specified for one column. -
You cannot specify a
PRIMARYKEYin both theColumnDefinitionclause and thePRIMARYKEYclause. -
For both primary key and foreign key constraints, duplicate column names are not allowed in the constraint column list.
-
You cannot update primary key column(s) unless you update the column(s) to the same value.
-
There are performance considerations when you define out of line columns instead of inline columns:
-
Accessing data is slower because TimesTen does not store data contiguously with out of line columns.
-
Populating data is slower because TimesTen generates more logging operations.
-
Deleting data is slower because TimesTen performs more reclaim and logging operations.
-
Storing a column requires less overhead.
-
-
If
ON DELETE CASCADEis specified on a foreign key constraint for a child table, a user can delete rows from a parent table for which the user has theDELETEprivilege without requiring explicitDELETEprivilege on the child table. -
To change the
ON DELETE CASCADEtriggered action, drop then redefine the foreign key constraint. -
You cannot create a table that has a foreign key referencing a cached table.
-
UNIQUEcolumn constraint and default column values are not supported with materialized views. -
Use the
ALTER TABLEstatement to change the representation of the primary key index for a table. -
If you specify the
ASSelectQueryclause:-
Data types and data type lengths are derived from the
SelectQuery. Do not specify data types on the columns of the table you are creating. -
TimesTen defines on columns in the new table
NOT NULLconstraints that were explicitly created on the corresponding columns of the selected table ifSelectQueryselects the column rather than an expression containing the column. -
NOT NULLconstraints that were implicitly created by TimesTen on columns of the selected table (for example, primary keys) are carried over to the new table. You can override theNOT NULLconstraint on the selected table by defining the new column asNULL. For example:CREATE TABLE newtable (newcol NULL) AS SELECT (col) FROM tab;
-
NOT INLINE/INLINEattributes are carried over to the new table. -
Unique keys, foreign keys, indexes and column default values are not carried over to the new table.
-
If all expressions in
SelectQueryare columns, rather than expressions, then you can omit the columns from the table you are creating. In this case, the name of the columns are the same as the columns inSelectQuery. If theSelectQuerycontains an expression rather than a simple column reference, either specify a column alias or name the column in theCREATE TABLEstatement. -
Do not specify foreign keys on the table you are creating.
-
Do not specify the
SELECT FOR UPDATEclause inSelectQuery. -
The
ORDER BYclause is not supported when you use theASSelectQueryclause. -
SelectQuerycannot contain set operatorsUNION,MINUS,INTERSECT. -
In a replicated environment, be aware of the following.
To include a new table, including global temporary tables, into an active standby pair when the table is created, set
DDL_REPLICATION_LEVELto 2 or greater andDDL_REPLICATION_ACTIONtoINCLUDEbefore executing theCREATE TABLEstatement on the active database. In this configuration, the table is included in the active standby pair and is replicated to all databases in the replication scheme.If
DDL_REPLICATION_ACTIONis set toEXCLUDE, then the new table is not included in the active standby pair but is replicated to all databases in the replication scheme. Any DML issued on that table will not be replicated, as the table will not be part of the replication scheme. To enable DML replication for the table, you must execute theALTER ACTIVE STANDBY PAIR ... INCLUDE TABLEstatement to include the table. In this case, the table must be empty and present on all databases before executingALTER ACTIVE STANDBY PAIR ... INCLUDE TABLE, as the table contents will be truncated when this statement is executed.See "ALTER SESSION" for more information.
-
-
By default, a range index is created to enforce the primary key. Use the
UNIQUE HASHclause to specify a hash index for the primary key.-
If your application performs range queries using a table's primary key, then choose a range index for that table by omitting the
UNIQUE HASHclause. -
If your application performs only exact match lookups on the primary key, then a hash index may offer better response time and throughput. In such a case, specify the
UNIQUE HASHclause.
-
-
A hash index is created with a fixed size that remains constant for the life of the table or until the hash index is resized with the
ALTER TABLEstatement or when the index is dropped and recreated. A smaller hash index results in more hash collisions. A larger hash index reduces collisions but can waste memory. Hash key comparison is a fast operation, so a small number of hash collisions should not cause a performance problem for TimesTen.To ensure that your hash index is sized correctly, your application must indicate the expected size of your table with the value of the
RowPagesparameter of theSETPAGESclause. Compute this value by dividing the number of expected rows in your table by 256. For example, if your table has 256,000 rows, specify 1000 for the value of RowPages (256000/256=1000). -
At most 16 columns are allowed in a hash key.
-
ON DELETE CASCADEis supported on detail tables of a materialized view. If you have a materialized view defined over a child table, a deletion from the parent table causes cascaded deletes in the child table. This, in turn, triggers changes in the materialized view. -
The total number of rows reported by the
DELETEstatement does not include rows deleted from child tables as a result of theON DELETE CASCADEaction. -
For
ON DELETE CASCADE: Since different paths may lead from a parent table to a child table, the following rule is enforced:-
Either all paths from a parent table to a child table are "delete" paths or all paths from a parent table to a child table are "do not delete" paths. Specify
ON DELETE CASCADEon all child tables on the "delete" path. -
This rule does not apply to paths from one parent to different children or from different parents to the same child.
-
-
For
ON DELETE CASCADE, the following rule is also enforced.-
If a table is reached by a "delete" path, then all its children are also reached by a "delete" path.
-
-
For
ON DELETE CASCADEwith replication, the following restrictions apply:-
The foreign keys specified with
ON DELETE CASCADEmust match between the Master and subscriber for replicated tables. Checking is done at runtime. If there is an error, the receiver thread stops working. -
All tables in the delete cascade tree have to be replicated if any table in the tree is replicated. This restriction is checked when the replication scheme is created or when a foreign key with
ON DELETE CASCADEis added to one of the replication tables. If an error is found, the operation is aborted. You may be required to drop the replication scheme first before trying to change the foreign key constraint. -
You must stop the replication agent before adding or dropping a foreign key on a replicated table.
-
-
The data in a global temporary table is private to the current connection and does not need to be secured between users. Thus, global temporary tables do not require object privileges.
-
After you have defined an aging policy for the table, you cannot change the policy from LRU to time-based or from time-based to LRU. You must first drop aging and then alter the table to add a new aging policy.
-
The aging policy must be defined to change the aging state.
-
For the time-based aging policy, you cannot add or modify the aging column. This is because you cannot add or modify a
NOT NULLcolumn. -
LRU and time-based aging can be combined in one system. If you use only LRU aging, the aging thread wakes up based on the cycle specified for the whole database. If you use only time-based aging, the aging thread wakes up based on an optimal frequency. This frequency is determined by the values specified in the
CYCLEclause for all tables. If you use both LRU and time-based aging, then the thread wakes up based on a combined consideration of both types. -
The following rules determine if a row is accessed or referenced for LRU aging:
-
Any rows used to build the result set of a
SELECTstatement. -
Any rows used to build the result set of an
INSERT ... SELECTstatement. -
Any rows that are about to be updated or deleted.
-
-
Compiled commands are marked invalid and need recompilation when you either drop LRU aging from or add LRU aging to tables that are referenced in the commands.
-
Call the
ttAgingScheduleNowprocedure to schedule the aging process immediately regardless of the aging state. -
Aging restrictions:
-
LRU aging and time-based aging are not supported on detail tables of materialized views.
-
LRU aging and time-based aging are not supported on global temporary tables.
-
You cannot drop the column that is used for time-based aging.
-
The aging policy and aging state must be the same in all sites of replication.
-
Tables that are related by foreign keys must have the same aging policy.
-
For LRU aging, if a child row is not a candidate for aging, neither this child row nor its parent row are deleted.
ON DELETE CASCADEsettings are ignored. -
For time-based aging, if a parent row is a candidate for aging, then all child rows are deleted.
ON DELETE CASCADE(whether specified or not) is ignored.
-
Column-based compression of tables (TimesTen Classic)
You can compress tables at the column level, which stores data more efficiently. This eliminates redundant storage of duplicate values within columns and improves the performance of SQL queries that perform full table scans.
You can define one or more columns in a table to be compressed together, which is called a compressed column group. You can define one or more compressed column groups in each table.
A dictionary table is created for each compressed column group that contains a column with all the distinct values of the compressed column group. The compressed column group now contains a pointer to the row in the dictionary table for the appropriate value. The width of this pointer can be 1, 2, or 4 bytes long depending on the maximum number of entries you defined for the dictionary table. So if the sum of the widths of the columns in a compressed column group is wider than the 1, 2, or 4 byte pointer width, and if there are a lot of duplicate values of those column values, you have reduced the amount of space used by the table.
Figure 6-1 shows the compressed column group in the table pointing to the appropriate row in the dictionary table.
The dictionary table has a column of pointers to each of the distinct values. When the user configures the maximum number of distinct entries for the compressed column group, the size of the compressed column group is set as follows:
-
1 byte for a maximum number of entries of 255 (28-1). When the maximum number is between 1 and 255, the dictionary size is set to 255 (28-1) values and the compressed column group pointer column is 1 byte.
-
2 bytes for a maximum number of entries of 65,535 (216-1). When the maximum number is between 256 and 65,535, the dictionary size is set to 65,535 (216-1) values and the compressed column group pointer column is 2 bytes.
-
4 bytes for a maximum number of entries of 4,294,967,295 (232-1). When the maximum number is between 65,536 and 4,294,967,295, the dictionary size is set to 4,294,967,295 (232-1) values and the compressed column group pointer column is 4 bytes. This is the default.
Syntax: column-based compression (TimesTen Classic)
The syntax for ColumnBasedCompression is:
[COMPRESS (CompressColumns [,...])]
The CompressColumns syntax is as follows:
{ColumnDefinition | (ColumnDefinition [,...])} BY DICTIONARY
[MAXVALUES = CompressMax]Parameters
ColumnBasedCompression syntax has the following parameters:
| Parameter | Description |
|---|---|
|
|
Defines a compressed column group for a table that is enabled for compression. This can include one or more columns in the table. However, a column can be included in only one compressed column group. Only Each compressed column group is limited to a maximum of 16 columns. |
|
|
Defines a compression dictionary for each compressed column group. |
|
|
For the dictionary table,
The maximum size defaults to size of 232-1 if the |
Description: column-based compression (TimesTen Classic)
-
Compressed column groups can be added at the time of table creation or added later using
ALTER TABLE. You can drop a compressed column group with theALTER TABLEstatement, but you must drop the entire group. -
You can create indexes on any columns in the table and on columns that exist in separate compression column groups. However, you cannot create single column compression groups on unique columns or on single column primary keys. You also cannot create unique indexes or primary keys where all the indexes or primary keys are in the same compression group.
-
LOB columns cannot be compressed.
-
Compression is not supported on columns in replicated tables, cache group tables, or on global temporary tables. You cannot create a table with the
CREATE TABLE AS SELECTstatement when defining column-based compression for that table in that statement. -
You cannot create materialized views on tables enabled for compression.
-
Column-based compression is not supported with TimesTen Scaleout.
Examples: TimesTen Classic
A range index is created on partnumber because it is the primary key.
Command> CREATE TABLE price
(partnumber INTEGER NOT NULL PRIMARY KEY,
vendornumber INTEGER NOT NULL,
vendpartnum CHAR(20) NOT NULL,
unitprice DECIMAL(10,2),
deliverydays SMALLINT,
discountqty SMALLINT);
Command> INDEXES price;
Indexes on table SAMPLEUSER.PRICE:
PRICE: unique range index on columns:
PARTNUMBER
1 index found.
1 index found on 1 table.
A hash index is created on column clubname, the primary key.
CREATE TABLE recreation.clubs (clubname CHAR(15) NOT NULL PRIMARY KEY, clubphone SMALLINT, activity CHAR(18)) UNIQUE HASH ON (clubname) PAGES = 30;
A range index is created on the two columns membername and club because together they form the primary key.
Command> CREATE TABLE recreation.members (membername CHAR(20) NOT NULL, club CHAR(15) NOT NULL, memberphone SMALLINT, PRIMARY KEY (membername, club)); Command> INDEXES recreation.members; Indexes on table RECREATION.MEMBERS: MEMBERS: unique range index on columns: MEMBERNAME CLUB 1 index found on 1 table.
No hash index is created on the table recreation.events.
CREATE TABLE recreation.events (sponsorclub CHAR(15), event CHAR(30), coordinator CHAR(20), results VARBINARY(10000));
A hash index is created on the column vendornumber.
CREATE TABLE purchasing.vendors (vendornumber INTEGER NOT NULL PRIMARY KEY, vendorname CHAR(30) NOT NULL, contactname CHAR(30), phonenumber CHAR(15), vendorstreet CHAR(30) NOT NULL, vendorcity CHAR(20) NOT NULL, vendorstate CHAR(2) NOT NULL, vendorzipcode CHAR(10) NOT NULL, vendorremarks VARCHAR(60)) UNIQUE HASH ON (vendornumber) PAGES = 101;
A hash index is created on the columns membername and club because together they form the primary key.
CREATE TABLE recreation.members (membername CHAR(20) NOT NULL, club CHAR(15) NOT NULL, memberphone SMALLINT, PRIMARY KEY (membername, club)) UNIQUE HASH ON (membername, club) PAGES = 100;
A hash index is created on the columns firstname and lastname because together they form the primary key in the table authors. A foreign key is created on the columns authorfirstname and authorlastname in the table books that references the primary key in the table authors.
CREATE TABLE authors (firstname VARCHAR(255) NOT NULL, lastname VARCHAR(255) NOT NULL, description VARCHAR(2000), PRIMARY KEY (firstname, lastname)) UNIQUE HASH ON (firstname, lastname) PAGES=20; CREATE TABLE books (title VARCHAR(100), authorfirstname VARCHAR(255), authorlastname VARCHAR(255), price DECIMAL(5,2), FOREIGN KEY (authorfirstname, authorlastname) REFERENCES authors(firstname, lastname));
The following statement overrides the default character of VARCHAR columns and creates a table where one VARCHAR (10) column is NOT INLINE and one VARCHAR (144) is INLINE.
CREATE TABLE t1 (c1 VARCHAR(10) NOT INLINE NOT NULL, c2 VARCHAR(144) INLINE NOT NULL);
The following statement creates a table with a UNIQUE column for book titles.
CREATE TABLE books (title VARCHAR(100) UNIQUE, authorfirstname VARCHAR(255), authorlastname VARCHAR(255), price DECIMAL(5,2), FOREIGN KEY (authorfirstname, authorlastname) REFERENCES authors(firstname, lastname));
The following statement creates a table with a default value of 1 on column x1 and a default value of SYSDATE on column d.
CREATE TABLE t1 (x1 INT DEFAULT 1, d TIMESTAMP DEFAULT SYSDATE);
This example creates the rangex table and defines col1 as the primary key. A range index is created by default.
Command> CREATE TABLE rangex (col1 TT_INTEGER PRIMARY KEY); Command> INDEXES rangex; Indexes on table SAMPLEUSER.RANGEX: RANGEX: unique range index on columns: COL1 1 index found 1 index found on 1 table.
The following statement illustrates the use of the ON DELETE CASCADE clause for parent/child tables of the HR schema. Tables with foreign keys have been altered to enable ON DELETE CASCADE.
ALTER TABLE countries ADD CONSTRAINT countr_reg_fk FOREIGN KEY (region_id) REFERENCES regions(region_id) ON DELETE CASCADE; ALTER TABLE locations ADD CONSTRAINT loc_c_id_fk FOREIGN KEY (country_id) REFERENCES countries(country_id) ON DELETE CASCADE; ALTER TABLE departments ADD CONSTRAINT dept_loc_fk FOREIGN KEY (location_id) REFERENCES locations (location_id) ON DELETE CASCADE; ALTER TABLE employees ADD CONSTRAINT emp_dept_fk FOREIGN KEY (department_id) REFERENCES departments ON DELETE CASCADE; ALTER TABLE employees ADD CONSTRAINT emp_job_fk FOREIGN KEY (job_id) REFERENCES jobs (job_id); ALTER TABLE job_history ADD CONSTRAINT jhist_job_fk FOREIGN KEY (job_id) REFERENCES jobs; ALTER TABLE job_history ADD CONSTRAINT jhist_emp_fk FOREIGN KEY (employee_id) REFERENCES employees ON DELETE CASCADE; ALTER TABLE job_history ADD CONSTRAINT jhist_dept_fk FOREIGN KEY (department_id) REFERENCES departments ON DELETE CASCADE; ;
This example shows how time resolution works with aging.
If lifetime is three days (resolution is in days):
-
If
(SYSDATE -ColumnValue) <= 3, do not age. -
If
(SYSDATE -ColumnValue) > 3, then the row is a candidate for aging. -
If
(SYSDATE -ColumnValue) = 3 days, 22 hours, then the row is not aged out if you specified a lifetime of three days. The row would be aged out if you had specified a lifetime of 72 hours.
This example creates a table with LRU aging. Aging state is ON by default.
CREATE TABLE agingdemo (agingid NUMBER NOT NULL PRIMARY KEY, name VARCHAR2 (20) ) AGING LRU; Command> DESCRIBE agingdemo; Table USER.AGINGDEMO: Columns: *AGINGID NUMBER NOT NULL NAME VARCHAR2 (20) INLINE AGING LRU ON 1 table found. (primary key columns are indicated with *)
This example creates a table with time-based aging. Lifetime is three days. Cycle is not specified, so the default is five minutes. Aging state is OFF.
CREATE TABLE agingdemo2 (agingid NUMBER NOT NULL PRIMARY KEY, name VARCHAR2 (20), agingcolumn TIMESTAMP NOT NULL ) AGING USE agingcolumn LIFETIME 3 DAYS OFF; Command> DESCRIBE agingdemo2; Table USER.AGINGDEMO2: Columns: *AGINGID NUMBER NOT NULL NAME VARCHAR2 (20) INLINE AGINGCOLUMN TIMESTAMP (6) NOT NULL Aging use AGINGCOLUMN lifetime 3 days cycle 5 minutes off 1 table found. (primary key columns are indicated with *)
This example generates an error message. It illustrates that after you create an aging policy, you cannot change it. You must drop aging and redefine aging.
CREATE TABLE agingdemo2 (agingid NUMBER NOT NULL PRIMARY KEY, name VARCHAR2 (20), agingcolumn TIMESTAMP NOT NULL ) AGING USE agingcolumn LIFETIME 3 DAYS OFF; ALTER TABLE agingdemo2 ADD AGING LRU; 2980: Cannot add aging policy to a table with an existing aging policy. Have to drop the old aging first The command failed. DROP aging on the table and redefine with LRU aging. ALTER TABLE agingdemo2 DROP AGING; ALTER TABLE agingdemo2 ADD AGING LRU; Command> DESCRIBE agingdemo2; Table USER.AGINGDEMO2: Columns: *AGINGID NUMBER NOT NULL NAME VARCHAR2 (20) INLINE AGINGCOLUMN TIMESTAMP (6) NOT NULL Aging lru on 1 table found. (primary key columns are indicated with *)
Attempt to create a table with time-based aging. Define aging column with data type TT_DATE and LIFETIME 3 hours. An error is generated because the LIFETIME unit must be expressed as DAYS.
Command> CREATE TABLE aging1 (col1 TT_INTEGER PRIMARY KEY, col2 TT_DATE NOT NULL) AGING USE col2 LIFETIME 3 HOURS; 2977: Only DAY lifetime unit is allowed with a TT_DATE column The command failed.
Use AS SelectQuery clause to create the table emp. Select last_name from the employees table where employee_id between 100 and 105. You see six rows inserted into emp. First issue the SELECT statement to see rows that should be returned.
Command> SELECT last_name FROM employees WHERE employee_id BETWEEN 100 AND 105; < King > < Kochhar > < De Haan > < Hunold > < Ernst > < Austin > 6 rows found. Command> CREATE TABLE emp AS SELECT last_name FROM employees WHERE employee_id BETWEEN 100 AND 105; 6 rows inserted. Command> SELECT * FROM emp; < King > < Kochhar > < De Haan > < Hunold > < Ernst > < Austin > 6 rows found.
Use AS SelectQuery to create table totalsal. Sum salary and insert result into totalsalary. Define alias s for SelectQuery expression.
Command> CREATE TABLE totalsal AS SELECT SUM (salary) s FROM employees; 1 row inserted. Command> SELECT * FROM totalsal; < 691400 > 1 row found.
Use AS SelectQuery to create table defined with column commission_pct. Set default to .3. First describe table employees to show that column commission_pct is of type NUMBER (2,2). For table c_pct, column commission_pct inherits type NUMBER (2,2) from column commission_pct of employees table.
Command> DESCRIBE employees; Table SAMPLEUSER.EMPLOYEES: Columns: *EMPLOYEE_ID NUMBER (6) NOT NULL FIRST_NAME VARCHAR2 (20) INLINE LAST_NAME VARCHAR2 (25) INLINE NOT NULL EMAIL VARCHAR2 (25) INLINE UNIQUE NOT NULL PHONE_NUMBER VARCHAR2 (20) INLINE HIRE_DATE DATE NOT NULL JOB_ID VARCHAR2 (10) INLINE NOT NULL SALARY NUMBER (8,2) COMMISSION_PCT NUMBER (2,2) MANAGER_ID NUMBER (6) DEPARTMENT_ID NUMBER (4) 1 table found. (primary key columns are indicated with *) Command> CREATE TABLE c_pct (commission_pct DEFAULT .3) AS SELECT commission_pct FROM employees; 107 rows inserted. Command> DESCRIBE c_pct; Table SAMPLEUSER.C_PCT: Columns: COMMISSION_PCT NUMBER (2,2) DEFAULT .3 1 table found. (primary key columns are indicated with *)
The following example creates the employees table where the job_id is compressed.
Command> CREATE TABLE EMPLOYEES
(EMPLOYEE_ID NUMBER (6) PRIMARY KEY,
FIRST_NAME VARCHAR2(20),
LAST_NAME VARCHAR2(25) NOT NULL,
EMAIL VARCHAR2(25) NOT NULL,
PHONE_NUMBER VARCHAR2(20),
HIRE_DATE DATE NOT NULL,
JOB_ID VARCHAR2(10) NOT NULL,
SALARY NUMBER (8,2),
COMMISSION_PCT NUMBER (2,2),
MANAGER_ID NUMBER(6),
DEPARTMENT_ID NUMBER(4))
COMPRESS (JOB_ID BY DICTIONARY);
Command> DESCRIBE EMPLOYEES;
Table MYSCHEMA.EMPLOYEES:
Columns:
*EMPLOYEE_ID NUMBER (6) NOT NULL
FIRST_NAME VARCHAR2 (20) INLINE
LAST_NAME VARCHAR2 (25) INLINE NOT NULL
EMAIL VARCHAR2 (25) INLINE NOT NULL
PHONE_NUMBER VARCHAR2 (20) INLINE
HIRE_DATE DATE NOT NULL
JOB_ID VARCHAR2 (10) INLINE NOT NULL
SALARY NUMBER (8,2)
COMMISSION_PCT NUMBER (2,2)
MANAGER_ID NUMBER (6)
DEPARTMENT_ID NUMBER (4)
COMPRESS ( JOB_ID BY DICTIONARY )
1 table found.
(primary key columns are indicated with *)
The following example shows that there are three dictionary table sizes. The value you specify for the maximum number of entries is rounded up to the next size. For example, specifying 400 as the maximum number of job IDs creates a dictionary table that can have at most 65535 entries. The default size of 232-1 is not shown in the DESCRIBE output.
Command> CREATE TABLE employees
(employee_id NUMBER(6) PRIMARY KEY,
first_name VARCHAR2(20),
last_name VARCHAR2(25),
email VARCHAR2(25) NOT NULL,
job_id VARCHAR2(10) NOT NULL,
manager_id NUMBER(6),
department_id NUMBER(4))
COMPRESS (last_name BY DICTIONARY MAXVALUES=70000,
job_id BY DICTIONARY MAXVALUES=400,
department_id BY DICTIONARY MAXVALUES=100);
Command> DESCRIBE employees;
Table MYSCHEMA.EMPLOYEES:
Columns:
*EMPLOYEE_ID NUMBER (6) NOT NULL
FIRST_NAME VARCHAR2 (20) INLINE
LAST_NAME VARCHAR2 (25) INLINE
EMAILS VARCHAR2 (25) INLINE NOT NULL
JOB_ID VARCHAR2 (10) INLINE NOT NULL
MANAGER_ID NUMBER (6)
DEPARTMENT_ID NUMBER (4)
COMPRESS ( LAST_NAME BY DICTIONARY,
JOB_ID BY DICTIONARY MAXVALUES=65535,
DEPARTMENT_ID BY DICTIONARY MAXVALUES=255 )
1 table found.
(primary key columns are indicated with *)See also:
CREATE USER
The CREATE USER statement creates a user in the TimesTen database.
Required privilege
ADMIN
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
CREATE USER user IDENTIFIED BY {password | "password"} [PROFILE profile] [ACCOUNT {LOCK|UNLOCK}] [PASSWORD EXPIRE]
or
CREATE USER user IDENTIFIED EXTERNALLY [PROFILE profile] [ACCOUNT {LOCK|UNLOCK}]
Parameters
| Parameter | Description |
|---|---|
|
|
Name of the user. |
|
|
Identification clause for an internal user. You must supply a password for an internal user. The password you can specify is dependent on the profile assigned to the user. Specifically, the value of the |
|
|
Identifies an external user (the operating system user). To perform database operations as an external user, the external user name must match the user name authenticated by the operating system or network. A password is not required by TimesTen as the user has been authenticated by the operating system at login time. |
|
|
Use the |
|
|
Specify |
|
|
Specify |
Description
-
Database users can be internal or external.
-
Internal users are defined for a TimesTen database.
-
External users are defined by the operating system. External users cannot be assigned a TimesTen password.
-
- Password requirements:
- Cannot exceed 30 characters.
- Is case-sensitive.
- Must start with a letter. A password cannot start with a digit or a special character unless the password is enclosed in double quotation marks.
- If a special character is used, the password must be contained in double quotation marks. The exceptions are the
#and the@special characters. A password that contains the#or the@special character does not need to be enclosed in double quotation marks. - Cannot contain a semi-colon (
;) or a double quotation mark (").
-
When a user is created, the user has the privileges granted to
PUBLICand no additional privileges. -
Use the
PROFILEclause to assign a profile to a user. If you assign the profile to an internal user, the user cannot exceed the limits specified for the profile. If you do not assign a profile to an internal user, aDEFAULTprofile is assigned to that user. See "CREATE PROFILE" for details. -
Use the
ACCOUNTLOCKorACCOUNTUNLOCKto lock or unlock the user account. -
Use the
PASSWORDEXPIREclause to expire the user's password and force a password change before the user can connect to the database. -
You can create a user over a client/sever connection if the connection is encrypted with TLS. See "Transport Layer Security for TimesTen Client/Server" in the Oracle TimesTen In-Memory Database Security Guide for details.
-
In TimesTen, user
bradis the same as user"brad". In both cases, the name of the user is created asBRAD. -
User names are
TT_CHARdata type. -
This statement is replicated.
Examples
Create users and observe password verification
This example creates the user_pw1 user and does not assign a profile to the user1_pw user. The user is subject to the limits of the DEFAULT profile. The PASSWORD_COMPLEXITY_CHECKER password parameter is set to NULL for the DEFAULT profile. Therefore, there is no password verification performed on this user's password. The example then alters the DEFAULT profile, changing the value of the PASSWORD_COMPLEXITY_CHECKER to TT_VERIFY_FUNCTION. The user1_p1 user can still connect to the database with the original password. Password verification is performed only on newly created users.
Command> CREATE USER user_pw1 IDENTIFIED BY user1_pw1;
User created.dba_profiles system view to check the limits of the password parameters for the DEFAULT profile. The PASSWORD_COMPLEXITY_CHECKER password parameter has a value of NULL.Command> SELECT * FROM dba_profiles WHERE profile = 'DEFAULT';
< DEFAULT, FAILED_LOGIN_ATTEMPTS, PASSWORD, 10 >
< DEFAULT, PASSWORD_LIFE_TIME, PASSWORD, UNLIMITED >
< DEFAULT, PASSWORD_REUSE_TIME, PASSWORD, UNLIMITED >
< DEFAULT, PASSWORD_REUSE_MAX, PASSWORD, UNLIMITED >
< DEFAULT, PASSWORD_COMPLEXITY_CHECKER, PASSWORD, NULL >
< DEFAULT, PASSWORD_LOCK_TIME, PASSWORD, .0034 >
< DEFAULT, PASSWORD_GRACE_TIME, PASSWORD, UNLIMITED >
< DEFAULT, TEMP_SPACE_PER_SESSION_MAX, MEMORY, UNLIMITED >
8 rows found.
DEFAULT profile, changing the value of the PASSWORD_COMPLEXITY_CHECKER parameter to TT_VERIFY_FUNCTION. Attempt to connect to the database as the user_pw1 user. The connection is successful, as password verification is only performed on newly created passwords. Command> ALTER PROFILE "DEFAULT" LIMIT
PASSWORD_COMPLEXITY_CHECKER TT_VERIFY_FUNCTION;
Profile altered.
Command> connect adding "UID=user_pw1;PWD=user_pw1" as user1;
Connection successful: DSN=access1;UID=user_pw1;
DataStore=/scratch/user1/mydatabase1;DatabaseCharacterSet=AL32UTF8;
ConnectionCharacterSet=AL32UTF8;PermSize=128;
(Default setting AutoCommit=1)user_pw2 user and specify user_pw2 for the password. The CREATE USER statement fails. Password verification is performed on the password for user_pw2, as the password is a newly created password. Create the user_pw2 user again, specifying a password that meets the requirements of the TT_VERIFY_FUNCTION function. The CREATE USER statement is successful, and the user is created. See "TT_VERIFY_FUNCTION" for more information on the TT_VERIFY_FUNCTION function.Command> CREATE USER user_pw2 IDENTIFIED BY user_pw2;
15186: Password complexity check for the specified password failed
15188: TT-20002: Password contains the username
The command failed.
Command> CREATE USER user_pw2 IDENTIFIED BY abc75#n4;
User created.Create user with TT_STRONG_VERIFY_FUNCTION password requirements
TT_STRONG_VERIFY_FUNCTION function. Create the profile_pw3 profile and specify a value of TT_STRONG_VERIFY_FUNCTION for the PASSWORD_COMPLEXITY_CHECKER password parameter. Create the user_pw3 user and assign this user the profile_pw3 profile. Experiment with different passwords to confirm that the password meets the requirements of the TT_STRONG_VERIFY_FUNCTION function. If the password meets the requirements, the CREATE USER statement is successful and the user is created. See "TT_STRONG_VERIFY_FUNCTION" for more information on the TT_STRONG_VERIFY_FUNCTION function.Command> CREATE PROFILE profile_pw3 LIMIT
PASSWORD_COMPLEXITY_CHECKER TT_STRONG_VERIFY_FUNCTION;
Profile created.user_pw3 user and experiment with various passwords. Recall that special characters must be enclosed in double quotation marks (with the exception of # and @).Command> CREATE USER user_pw3 IDENTIFIED BY abcABC1#
PROFILE profile_pw3;
15186: Password complexity check for the specified password failed
15188: TT-20001: Password length less than 9
The command failed.
Command> CREATE USER user_pw3 IDENTIFIED BY abcABCD1#
PROFILE profile_pw3;
15186: Password complexity check for the specified password failed
15188: TT-20001: Password must contain at least 2 digit(s)
The command failed.
Command> CREATE USER user_pw3 IDENTIFIED BY abcABCD11#
PROFILE profile_pw3;
15186: Password complexity check for the specified password failed
15188: TT-20001: Password must contain at least 2 special character(s)
The command failed.
Command> CREATE USER user_pw3 IDENTIFIED BY "!abcABCD11#"
PROFILE profile_pw3;
User created.Create a user and assign a profile
This example creates the user1 user and assigns the profile1 profile to the user.
Command> CREATE USER user1 IDENTIFIED BY user1 PROFILE profile1; User created.
Create a user and do not assign a profile
This example creates the user2 user and does not assign a profile. The user2 user is assigned the values of the password parameters in the DEFAULT profile.
Command> CREATE USER user2 identified by user2; User created.
Query the dba_users system view to verify the user2 user is assigned the DEFAULT profile.
Command> SELECT profile FROM dba_users WHERE username='USER2'; < DEFAULT > 1 row found.
Create a user and lock the user account
This example creates the user3 user and locks the user3 account. The user3 account must be unlocked by a user with the ADMIN privilege before the user3 user can connect to the database.
Command> CREATE USER user3 IDENTIFIED BY user3 ACCOUNT LOCK; User created.
Grant the CONNECT privilege to user3;
Command> GRANT CONNECT TO user3;
Attempt to connect to the database as user3. The user3 account is locked so the connection fails.
Command> connect adding "UID=user3;PWD=user3" as user3; 15179: the account is locked The command failed.
As the instance administrator, reconnect to the database and use the ALTER USER statement to unlock the user3 account.
none: Command> use database1 database1: Command> ALTER USER user3 ACCOUNT UNLOCK; User altered.
Attempt to connect to the database a the user3 user. The connection succeeds.
database1: Command> connect adding "UID=user3;PWD=user3" as user3; Connection successful: DSN=database1;UID=user3;DataStore=/scratch/database1; DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=AL32UTF8;PermSize=128; (Default setting AutoCommit=1)
Lock the user account and enforce a password change
This example creates the user4 user. The user4 user is assigned the profile1 profile. The user4 account is locked and the password for user4 must be changed before the user4 user can connect to the database.
Command> CREATE USER user4 identified by user4 PROFILE profile1
ACCOUNT LOCK PASSWORD EXPIRE;
User created.Attempt to connect to the database as user4. The user4 account is locked and the password must be changed before the user4 user can connect to the database.
Command> connect adding "UID=user4;PWD=user4" as user4; 15179: the account is locked The command failed.
As the instance administrator, reconnect to the database and use the ALTER USER statement to unlock the user4 account.
none: Command> use database1 database1: Command> ALTER USER user4 ACCOUNT UNLOCK; User altered.
Grant the CONNECT privilege to user4. Then change the user4's expired password. (This example changes the password to user4_changed, represented in bold.)
database1: Command> GRANT CONNECT TO user4; database1: Command> ALTER USER user4 IDENTIFIED BY user4_changed; User altered.
Attempt to connect to the database as the user4 user. The connection succeeds. The account is unlock and the password is changed.
database1: Command> connect adding "UID=user4;PWD=user4_changed" as user4; Connection successful: DSN=database1;UID=user4;DataStore=/scratch/database1; DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=AL32UTF8;PermSize=128; (Default setting AutoCommit=1)
Create an external user
This example creates the user5 user as an external user.
Command> CREATE USER user5 IDENTIFIED EXTERNALLY; User created.
CREATE VIEW
The CREATE VIEW statement creates a view of the tables specified in the SelectQuery clause. A view is a logical table that is based on one or more detail tables. The view itself contains no data. It is sometimes called a nonmaterialized view to distinguish it from a materialized view, which does contain data that has already been calculated from detail tables.
In a replicated environment for an active standby pair, if DDL_REPLICATION_LEVEL is 3 or greater when you execute CREATE VIEW on the active database, the view is replicated to all databases in the replication scheme. See "Making DDL changes in an active standby pair" in the Oracle TimesTen In-Memory Database Replication Guide for more information.
Required privilege
The user executing the statement must have the CREATE VIEW privilege (if owner) or CREATE ANY VIEW (if not the owner) for another user's view.
The owner of the view must have the SELECT privilege on the detail tables.
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
CREATE VIEW [Owner.]ViewNameASSelectQuery
Parameters
| Parameter | Description |
|---|---|
|
|
Name of view |
|
|
Selects column from the detail tables to be used in the view. You can also create indexes on the view. |
Restrictions on the SELECT query
There are several restrictions on the query that is used to define the view.
-
A
SELECT *query in a view definition is expanded when the view is created. Any columns added after a view is created do not affect the view. -
Do not use the following in a
SELECTstatement that is used to create a view:-
FIRST -
ORDER BYIf used, this is ignored by
CREATE VIEW. The result will not be sorted. -
Arguments
-
-
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.
ROWIDis considered an expression and needs an alias. -
Do not use
SELECT FOR UPDATEto create 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.
-
When a view is referenced in the
FROMclause of aSELECTstatement, its name is replaced by its definition as a derived table at parsing time. If it is not possible to merge all clauses of a view to the same clause in the original select query to form a supported query without the derived table, the content of this derived table is materialized. 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. -
Use the
DROP VIEWstatement to drop a view. -
A view cannot be altered with an
ALTER TABLEstatement. -
Referencing a view can fail because of dropped or altered detail tables.
Examples
Create a nonmaterialized view from the employees table.
Command> CREATE VIEW v1 AS SELECT employee_id, email FROM employees; Command> SELECT FIRST 5 * FROM v1; < 100, SKING > < 101, NKOCHHAR > < 102, LDEHAAN > < 103, AHUNOLD > < 104, BERNST > 5 rows found.
Create a nonmaterialized view tview with column max1 from an aggregate query on the table t1.
CREATE VIEW tview (max1) AS SELECT MAX(x1) FROM t1;
DELETE
The DELETE statement deletes rows from a table.
Required privilege
No privilege is required for the table owner.
DELETE on the table for another user's table.
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
DELETE [hint] [FIRST NumRows] FROM [Owner.]TableName [CorrelationName] [WHERE SearchCondition] [RETURNING|RETURN Expression[,...]INTO DataItem[,...]]
Parameters
| Parameter | Description |
|---|---|
|
|
Specifies a statement level optimizer hint for the |
|
|
Specifies the number of rows to delete. |
|
|
Designates a table from which any rows satisfying the search condition are to be deleted.
|
|
|
Specifies which rows are to be deleted. If no rows satisfy the search condition, the table is not changed. If the |
|
|
Valid expression syntax. See Expressions for details. |
|
|
Host variable or PL/SQL variable that stores the retrieved |
Description
-
If all the rows of a table are deleted, the table is empty but continues to exist until you issue a
DROP TABLEstatement. -
If your table has out of line columns and there are millions of rows to delete, consider calling the
ttCompactbuilt-in procedure to free memory. -
The
DELETEoperation fails if it violates any foreign key constraint. See "CREATE TABLE" for a description of the foreign key constraint. -
The total number of rows reported by the
DELETEstatement does not include rows deleted from child tables as a result of theON DELETE CASCADEaction. -
If
ON DELETE CASCADEis specified on a foreign key constraint for a child table, a user can delete rows from a parent table for which the user has theDELETEprivilege without requiring explicitDELETEprivilege on the child table. -
Restrictions on the
RETURNINGclause:-
Each
Expressionmust be a simple expression. Aggregate functions are not supported. -
You cannot return a sequence number into an
OUTparameter. -
ROWNUMand subqueries cannot be used in theRETURNINGclause. -
Parameters in the
RETURNINGclause cannot be duplicated anywhere in theDELETEstatement. -
Using the
RETURNINGclause to return multiple rows requires PL/SQLBULK COLLECTfunctionality. See "FORALL and BULK COLLECT operations" in Oracle TimesTen In-Memory Database PL/SQL Developer's Guide for information aboutBULK COLLECT. -
In PL/SQL, you cannot use a
RETURNINGclause with aWHERE CURRENToperation.
-
Examples
Rows for orders whose quantity is less than 50 are deleted.
DELETE FROM purchasing.orderitems WHERE quantity < 50;
The following query deletes all the duplicate orders assuming that id is not a primary key:
DELETE FROM orders a WHERE EXISTS (SELECT 1 FROM orders b WHERE a.id = b.id and a.rowid < b.rowid);
The following sequence of statements causes a foreign key violation.
CREATE TABLE master (name CHAR(30), id CHAR(4) NOT NULL PRIMARY KEY);
CREATE TABLE details
(masterid CHAR(4),description VARCHAR(200),
FOREIGN KEY (masterid) REFERENCES master(id));
INSERT INTO master('Elephant', '0001');
INSERT INTO details('0001', 'A VERY BIG ANIMAL');
DELETE FROM master WHERE id = '0001';
If you attempt to delete a "busy" table, an error results. In this example, t1 is a "busy" table that is a parent table with foreign key constraints based on it.
CREATE TABLE t1 (a INT NOT NULL, b INT NOT NULL, PRIMARY KEY (a)); CREATE TABLE t2 (c INT NOT NULL, FOREIGN KEY (c) REFERENCES t1(a)); INSERT INTO t1 VALUES (1,1); INSERT INTO t2 VALUES (1); DELETE FROM t1;
An error is returned:
SQL ERROR (3001): Foreign key violation [TTFOREIGN_0] a row in child table T2 has a parent in the delete range.
Delete an employee from employees. Declare empid and name as variables with the same data types as employee_id and last_name. Delete the row, returning employee_id and last_name into the variables. Verify that the correct row was deleted.
Command> VARIABLE empid NUMBER(6) NOT NULL;
Command> VARIABLE name VARCHAR2(25) INLINE NOT NULL;
Command> DELETE FROM employees WHERE last_name='Ernst'
RETURNING employee_id, last_name INTO :empid,:name;
1 row deleted.
Command> PRINT empid name;
EMPID : 104
NAME : ErnstDROP ACTIVE STANDBY PAIR
This statement is not supported in TimesTen Scaleout.
In TimesTen Classic:
This statement drops an active standby pair replication scheme.
Required privilege
ADMIN
Usage with TimesTen Scaleout
This statement is not supported with TimesTen Scaleout.
SQL syntax
DROP ACTIVE STANDBY PAIR
Parameters
DROP ACTIVE STANDBY PAIR has no parameters.
Description
The active standby pair is dropped, but all objects such as tables, cache groups, and materialized views still exist on the database on which the statement was issued.
You cannot execute the DROP ACTIVE STANDBY PAIR statement when Oracle Clusterware is used with TimesTen.
DROP CACHE GROUP
This statement is supported in TimesTen Scaleout.
In TimesTen Classic:
The DROP CACHE GROUP statement drops the table associated with the cache group, and removes the cache group definition from the CACHE_GROUP system table.
Required privilege
No privilege is required for the cache group owner.
If not the cache group owner, DROP ANY CACHE GROUP and
DROP ANY TABLE if at least one table in the cache group is not owned by the current user.
Usage with TimesTen Scaleout
This statement is not supported with TimesTen Scaleout.
SQL syntax
DROP CACHE GROUP [Owner.]GroupName
Parameters
| Parameter | Description |
|---|---|
|
|
Name of the cache group to be deleted. |
Description
-
If you attempt to delete a cache group table that is in use, TimesTen returns an error.
-
Asynchronous writethrough cache groups cannot be dropped while the replication agent is running.
-
Automatically installed Oracle Database objects for read-only cache groups and cache groups with the
AUTOREFRESHattribute are uninstalled by the cache agent. If the cache agent is not running during theDROP CACHE GROUPoperation, the Oracle Database objects are uninstalled on the next startup of the cache agent. -
You cannot execute the
DROP CACHE GROUPstatement when performed under the serializable isolation level. An error message is returned when attempted. -
If you issue a
DROP CACHE GROUPstatement, and there is an autorefresh operation currently running, then:-
If
LockWaitinterval is 0, theDROP CACHE GROUPstatement fails with a lock timeout error. -
If
LockWaitinterval is nonzero, then the current autorefresh transaction is preempted (rolled back), and theDROPstatement continues. This affects all cache groups with the same autorefresh interval.
-
Examples
DROP CACHE GROUP westerncustomers;
See also
DROP FUNCTION
The DROP FUNCTION statement removes a standalone stored function from the database. Do not use this statement to remove a function that is part of a package.
Required privilege
No privilege is required for the function owner.
DROP ANY PROCEDURE for another user's function.
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
DROP FUNCTION [Owner.]FunctionName
Parameters
| Parameter | Description |
|---|---|
|
|
Name of the function to be dropped. |
Description
-
When you drop a function, TimesTen invalidates objects that depend on the dropped function. If you subsequently reference one of these objects, TimesTen attempts to recompile the object and returns an error message if you have not recreated the dropped function.
-
Do not use this statement to remove a function that is part of a package. Either drop the package or redefine the package without the function using the
CREATE PACKAGEstatement with theOR REPLACEclause. -
To use the
DROP FUNCTIONstatement, you must have PL/SQL enabled in your database. If you do not have PL/SQL enabled in your database, an error is thrown.
Examples
The following statement drops the function myfunc and invalidates all objects that depend on myfunc:
Command> DROP FUNCTION myfunc; Function dropped.
If PL/SQL is not enabled in your database, TimesTen returns an error:
Command> DROP FUNCTION myfunc; 8501: PL/SQL feature not installed in this TimesTen database The command failed.
See also
DROP INDEX
The DROP INDEX statement deletes the specified index. The index can be global (TimesTen Scaleout or local (TimesTen Scaleoutor TimesTen Classic.
Required privilege
No privilege is required for the index owner. DROP ANY INDEX is required for an index owned by another user.
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout. Use the DROP INDEX statement to drop both global and local indexes.
SQL syntax
DROP INDEX [Owner.]IndexName [FROM [Owner.]TableName]
Parameters
| Parameter | Description |
|---|---|
|
|
Name of the index to be dropped. You can include the name of the owner of the table for the index. For TimesTen Scaleout, the index can be global or local. |
|
|
Name of the table upon which the index was created. |
Description
-
If you attempt to drop a "busy" index—an index that is in use or that enforces a foreign key—an error results. To drop a foreign key and the index associated with it, use the
ALTER TABLEstatement. -
If an index is created on a
UNIQUEcolumn constraint, it can only be dropped by dropping the constraint. Use theALTER TABLEDROP UNIQUEstatement for this purpose. Also, see "CREATE TABLE" for more information about theUNIQUEcolumn constraint. -
If a
DROP INDEXoperation is or was active in an uncommitted transaction, other transactions that are performing DML operations, that do not access that index, are blocked. -
If an index is dropped, any prepared statement that uses the index is automatically prepared again the next time the statement is executed.
-
If no table name is specified, the index name must be unique for the specified or implicit owner.
-
If no index owner is specified and a table is specified, the default owner is the table owner.
-
If a table is specified and no owner is specified for it, the default table owner is the current user.
-
The table and index owners must be the same.
-
An index on a temporary table cannot be dropped by a connection if some other connection has an instance of the table that is not empty.
-
If the index is replicated across an active standby pair and if
DDL_REPLICATION_LEVELis 2 or greater, use theDROP INDEXstatement to drop the index from the active standby pair in the replication scheme. See "Making DDL changes in an active standby pair" in the Oracle TimesTen In-Memory Database Replication Guide for more information.
Examples
Drop index partsorderedindex which is defined on table orderitems using one of the following:
DROP INDEX partsorderedindex FROM purchasing.orderitems;
Or:
DROP INDEX purchasing.partsorderedindex;
See also
DROP MATERIALIZED VIEW
The DROP MATERIALIZED VIEW statement removes the specified materialized view, including any hash indexes and any range indexes associated with it.
Required privilege
View owner or DROP ANY MATERIALIZED VIEW (if not owner) and
Table owner or DROP ANY TABLE (if not owner) and
Index owner or DROP ANY INDEX (if not owner) if there is an index on the view.
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
DROP MATERIALIZED VIEW [Owner.]ViewName
Parameters
| Parameter | Description |
|---|---|
|
|
Identifies the materialized view to be dropped. |
Description
When you execute a DROP MATERIALIZED VIEW operation, the detail tables are updated and locked. An error may result if the detail table was already locked by another transaction.
Examples
The following statement drops the custorder materialized view.
DROP MATERIALIZED VIEW custorder;
See also
DROP PACKAGE [BODY]
The DROP PACKAGE statement removes a stored package from the database. Both the specification and the body are dropped. DROP PACKAGE BODY removes only the body of the package.
Required privilege
No privilege is required for the package owner.
DROP ANY PROCEDURE for another user's package.
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
DROP PACKAGE [BODY] [Owner.]PackageName
Parameters
| Parameter | Description |
|---|---|
|
|
Specify |
|
|
Name of the package to be dropped. |
Description
-
When you drop only the body of the package, TimesTen does not invalidate dependent objects. However, you cannot execute one of the procedures or stored functions declared in the package specification until you recreate the package body.
-
TimesTen invalidates any objects that depend on the package specification. If you subsequently reference one of these objects, then TimesTen tries to recompile the object and returns an error if you have not recreated the dropped package.
-
Do not use this statement to remove a single object from the package. Instead, recreate the package without the object using the
CREATE PACKAGEandCREATE PACKAGE BODYstatements with theOR REPLACEclause. -
To use the
DROP PACKAGE [BODY]statement, you must have PL/SQL enabled in your database. If you do not have PL/SQL enabled in your database, TimesTen returns an error.
Example
The following statement drops the body of package samplePackage:
Command> DROP PACKAGE BODY SamplePackage; Package body dropped.
To drop both the specification and body of package samplepackage:
Command> DROP PACKAGE samplepackage; Package dropped.
See also
DROP PROCEDURE
The DROP PROCEDURE statement removes a standalone stored procedure from the database. Do not use this statement to remove a procedure that is part of a package.
Required privilege
No privilege is required for the procedure owner.
DROP ANY PROCEDURE for another user's procedure.
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
DROP PROCEDURE [Owner.]ProcedureName
Parameters
| Parameter | Description |
|---|---|
|
|
Name of the procedure to be dropped. |
Description
-
When you drop a procedure, TimesTen invalidates objects that depend on the dropped procedure. If you subsequently reference one of these objects, TimesTen attempts to recompile the object and returns an error message if you have not recreated the dropped procedure.
-
Do not use this statement to remove a procedure that is part of a package. Either drop the package or redefine the package without the procedure using the
CREATE PACKAGEstatement with theOR REPLACEclause. -
To use the
DROP PROCEDUREstatement, you must have PL/SQL enabled in your database. If you do not have PL/SQL enabled in your database, an error is thrown.
Examples
The following statement drops the procedure myproc and invalidates all objects that depend on myproc:
Command> DROP PROCEDURE myproc; Procedure dropped.
If PL/SQL is not enabled in your database, TimesTen returns an error:
Command> DROP PROCEDURE myproc; 8501: PL/SQL feature not installed in this TimesTen databaseThe command failed.
See also
DROP PROFILE
The DROP PROFILE statement removes a profile from the database.
Required privilege
ADMIN
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
DROP PROFILE profile [CASCADE]Parameters
| Parameter | Description |
|---|---|
|
|
Name of the profile to be dropped. |
|
|
Specify |
Description
-
Use this statement to drop an existing profile. You cannot drop the
DEFAULTprofile. See "CREATE PROFILE" for information on theDEFAULTprofile. -
If you create a profile that is not currently assigned to a user, you do not need to specify
CASCADEto drop the profile. If, however, the profile is currently assigned to a user, you must specifyCASCADEto drop the profile.
Example
This example creates the test_profile profile and the test_profile_assign_to_user profile. It then creates the test_user user and assigns the test_profile_assign_to_user profile to that user. The example attempts to drop the test_profile profile. The operation succeeds as there are no users assigned to this profile. The example then attempts to drop the test_profile_assign_to_user profile. The operation succeeds if CASCADE is specified. After the test_profile_assign_to_user profile is dropped, the test_user user is assigned the DEFAULT profile.
-
Create the
test_profileprofile. SetFAILED_LOGIN_ATTEMPTSto a value of5.Command> CREATE PROFILE test_profile LIMIT FAILED_LOGIN_ATTEMPTS 5; Profile created.
-
Create the
test_profile_assign_to_userprofile. SetFAILED_LOGIN_ATTEMPTSto a value of3.Command> CREATE PROFILE test_profile_assign_to_user LIMIT FAILED_LOGIN_ATTEMPTS 3; Profile created. -
Create the
test_useruser and assign thetest_profile_assign_to_userprofile to this user.Command> CREATE USER test_user identified by test_user_pwd PROFILE test_profile_assign_to_user; User created. -
Drop the
test_profileprofile. TheDROPPROFILEoperation succeeds. There are no users assigned to thistest_profileprofile.Command> DROP PROFILE test_profile; Profile dropped.
-
Attempt to drop the
test_profile_assign_to_userprofile. TheDROPPROFILEoperation fails. There is a user assigned to this profile. Repeat theDROPPROFILEoperation again, but this time specifyCASCADE. TheDROPPROFILEoperation succeeds.Command> DROP PROFILE test_profile_assign_to_user; 15178: Profile TEST_PROFILE_ASSIGN_TO_USER has users assigned, cannot drop without CASCADE The command failed. Command> DROP PROFILE test_profile_assign_to_user CASCADE; Profile dropped.
-
Query the
DBA_USERSsystem view to verify that thetest_useruser has been assigned theDEFAULTprofile.Command> SELECT profile FROM dba_users WHERE username = 'TEST_USER'; PROFILE < DEFAULT > 1 row found.
See also
DROP REPLICATION
This statement is not supported in TimesTen Scaleout.
In TimesTen Classic:
The DROP REPLICATION statement destroys a classic replication scheme and removes it from the executing database.
Required privilege
ADMIN
Usage with TimesTen Scaleout
This statement is not supported with TimesTen Scaleout.
SQL syntax
DROP REPLICATION [Owner.]ReplicationSchemeName
Parameters
| Parameter | Description |
|---|---|
|
|
Name assigned to the classic replication scheme. |
Description
Dropping the last replication scheme on a database does not delete the replicated tables. These tables exist and persist at a database whether any replication schemes are defined.
Examples
The following statement erases the executing database's knowledge of a classic replication scheme, r:
DROP REPLICATION r;
See also
DROP SEQUENCE
The DROP SEQUENCE statement removes an existing sequence number generator.
If the sequence is replicated across an active standby pair and if DDL_REPLICATION_LEVEL is 3 or greater, the DROP SEQUENCE statement drops the sequence from the active standby pair for all databases in the replication scheme. See "Making DDL changes in an active standby pair" in the Oracle TimesTen In-Memory Database Replication Guide for more information.
Required privilege
No privilege is required for the sequence owner.
DROP ANY SEQUENCE for another user's sequence.
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
DROP SEQUENCE [Owner.]SequenceName
Parameters
| Parameter | Description |
|---|---|
|
|
Name of the sequence number generator. |
Description
-
Sequences can be dropped while they are in use.
-
If you are using TimesTen Scaleout, you can modify the batch value with the
ALTERSEQUENCEstatement. Otherwise, to alter a sequence, use theDROP SEQUENCEstatement and then create a new sequence with the same name. For example, to change theMINVALUE, drop the sequence and recreate it with the same name and with the desiredMINVALUE. -
If the sequence is part of a replication scheme, use the
ALTER REPLICATIONstatement to drop the sequence from the replication scheme. Then use theDROP SEQUENCEstatement to drop the sequence.
Examples
The following statement drops mysequence:
DROP SEQUENCE mysequence;
See also
DROP SYNONYM
The DROP SYNONYM statement removes a synonym from the database.
If the synonym is replicated across an active standby pair and if DDL_REPLICATION_LEVEL is 2 or greater, the DROP SYNONYM statement drops the synonym from the active standby pair for all databases in the replication scheme. See "Making DDL changes in an active standby pair" in the Oracle TimesTen In-Memory Database Replication Guide for more information.
Required privilege
No privilege is required to drop the private synonym by its owner. The DROP ANY SYNONYM privilege is required to drop another user's private synonym.
The DROP PUBLIC SYNONYM privilege is required to drop a PUBLIC synonym.
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
To drop a private synonym, use the following syntax:
DROP SYNONYM [Owner.]SynonymName
To drop a public synonym:
DROP PUBLIC SYNONYM SynonymNameParameters
| Parameter | Description |
|---|---|
|
|
Specify |
|
|
Optionally, specify the owner for a private synonym. If you omit the owner, the private synonym must exist in the current user's schema. |
|
|
Specify the name of the synonym to be dropped. |
Examples
Drop the public synonym pubemp:
DROP PUBLIC SYNONYM pubemp; Synonym dropped.
Drop the private synjobs synonym:
DROP SYNONYM synjobs; Synonym dropped.
As user terry with DROP ANY SYNONYM privilege, drop the private syntab synonym owned by ttuser.
DROP SYNONYM ttuser.syntab; Synonym dropped.
See also
DROP TABLE
The DROP TABLE statement removes the specified table, including any hash indexes and any range indexes associated with it.
Required privilege
No privilege is required for the table owner.
DROP ANY TABLE for another user's table.
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
DROP TABLE [Owner.]TableName
Parameters
| Parameter | Description |
|---|---|
|
|
Identifies the table to be dropped. |
Description
-
If you attempt to drop a table that is in use, an error results.
-
If
DROP TABLEis or was active in an uncommitted transaction, other transactions doing DML operations that do not access that table are allowed to proceed. -
If the table is a replicated table, you can do one of the following:
-
Use the
DROP REPLICATIONstatement to drop the replication scheme before issuing theDROP TABLEstatement. -
If
DDL_REPLICATION_LEVELis 2 or greater, theDROP TABLEstatement drops the table from the active standby pair for all databases in the replication scheme.If
DDL_REPLICATION_LEVELis 1, stop the replication agent and use theALTER ACTIVE STANDBY PAIR ... EXCLUDE TABLEstatement to exclude the table from the replication scheme. Then use theDROP TABLEstatement to drop the table.See "Making DDL changes in an active standby pair" in the Oracle TimesTen In-Memory Database Replication Guide for more information.
-
-
A temporary table cannot be dropped by a connection if some other connection has some non-empty instance of the table.
Examples
CREATE TABLE vendorperf (ordernumber INTEGER, delivday TT_SMALLINT, delivmonth TT_SMALLINT, delivyear TT_SMALLINT, delivqty TT_SMALLINT, remarks VARCHAR2(60)); CREATE UNIQUE INDEX vendorperfindex ON vendorperf (ordernumber);
The following statement drops the table and index.
DROP TABLE vendorperf;
DROP USER
The DROP USER statement removes a user from the database.
Required privilege
ADMIN
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
DROP USER userParameters
| Parameter | Description |
|---|---|
|
|
Name of the user that is being dropped from the database. |
Description
Before you can drop a user:
-
The user must exist either internally or externally in the database.
-
You must drop objects that the user owns.
-
When replication is configured, this statement is replicated.
Examples
Drop user terry from the database:
DROP USER terry; User dropped.
See also
DROP VIEW
The DROP VIEW statement removes the specified view.
If the view is replicated across an active standby pair and if DDL_REPLICATION_LEVEL is 3 or greater, the DROP VIEW statement drops the view from the active standby pair for all databases in the replication scheme. See "Making DDL changes in an active standby pair" in the Oracle TimesTen In-Memory Database Replication Guide for more information.
Required privilege
View owner or DROP ANY VIEW (if not owner)
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
DROP VIEW [Owner.]ViewName
Parameters
| Parameter | Description |
|---|---|
|
|
Identifies the view to be dropped. |
Examples
The following statement drops the custorder view.
DROP VIEW custorder;
See also
FLUSH CACHE GROUP
This statement is not supported in TimesTen Scaleout.
In TimesTen Classic:
The FLUSH CACHE GROUP statement flushes data from TimesTen cache tables to Oracle Database tables. This statement is available only for user managed cache groups.
There are two variants to this operation: one that accepts a WHERE clause, and one that accepts a WITH ID clause.
FLUSH CACHE GROUP is meant to be used when commit propagation (from TimesTen to Oracle Database) is turned off. Instead of propagating every transaction upon commit, many transactions can be committed before changes are propagated to Oracle Database. For each cache instance ID, if the cache instance exists in the Oracle database, the operation in the Oracle database consists of an update. If the cache instance does not exist in the Oracle database, TimesTen inserts it.
This is useful, for example, in a shopping cart application in which many changes may be made to the cart, which uses TimesTen as a high-speed cache, before the order is committed to the master Oracle database table.
Note:
Using a WITH ID clause usually results in better system performance than using a WHERE clause.
Only inserts and updates are flushed. Inserts are propagated as inserts if the record does not exist in the Oracle database table or as updates (if the record already exists). It is not possible to flush a delete. That is, if a record is deleted on TimesTen, there is no way to "flush" that delete to the Oracle database table. Deletes must be propagated either manually or by turning commit propagation on. Attempts to flush deleted records are silently ignored. No error or warning is issued. Records from tables that are specified as READ ONLY or PROPAGATE cannot be flushed to the Oracle database tables.
Required privilege
No privilege is required for the cache group owner.
FLUSH or FLUSH ANY CACHE GROUP for another user's cache group.
INSERT, DELETE, UPDATE privileges on underlying tables.
Usage with TimesTen Scaleout
This statement is not supported with TimesTen Scaleout.
SQL syntax
FLUSH CACHE GROUP [Owner.]GroupName [WHERE ConditionalExpression]
or
FLUSH CACHE GROUP [Owner.]GroupName WITH ID (ColumnValueList)
Parameters
| Parameter | Description |
|---|---|
|
|
Name of the cache group to be flushed. |
|
|
Use the |
|
|
The |
Description
-
WHEREclauses are generally used to apply the operation to a set of cache instances, rather than to a single cache instance or to all cache instances. The flush operation uses theWHEREclause to determine which cache instances to send to the Oracle database. -
Generally, you do not have to fully qualify the column names in the
WHEREclause of theFLUSH CACHE GROUPstatement. However, since TimesTen automatically generates queries that join multiple tables in the same cache group, a column must be fully qualified if there is more than one table in the cache group that contains columns with the same name. Without an owner name, all tables referenced by cache groupWHEREclauses are owned by the current login name executing the cache group operation. -
When the
WHEREclause is omitted, the entire contents of the cache group is flushed to the Oracle database tables. When theWHEREclause is included, it is allowed to include only the root table. -
Following the execution of a
FLUSH CACHE GROUPstatement, the ODBC functionSQLRowCount(), the JDBC methodgetUpdateCount(), and the OCI functionOCIAttrGet()with theOCI_ATTR_ROW_COUNTargument return the number of cache instances that were flushed. -
Use the
WITH IDclause to specify binding parameters.
Restrictions
Do not use the WITH ID clause when flushing:
-
Static user managed cache group with the
AUTOREFRESHattribute -
AWT or SWT cache groups
Examples
FLUSH CACHE GROUP marketbasket; FLUSH CACHE GROUP marketbasket WITH ID(10);
See also
GRANT
The GRANT statement assigns one or more privileges to a user.
Required privilege
ADMIN to grant system privileges.
ADMIN or the object owner to grant object privileges.
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
GRANT {SystemPrivilege [,...] | ALL [PRIVILEGES]} [...] TO {user |PUBLIC} [,...]or
GRANT {{ObjectPrivilege [,...] | ALL [PRIVILEGES]} ON {[Owner.]object}[,...]} TO
{user | PUBLIC} [,...]Parameters
The following parameters are for granting system privileges:
| Parameter | Description |
|---|---|
|
|
This is the system privilege to grant. See "System privileges" for a list of acceptable values. |
|
|
Assigns all system privileges to the user. |
|
|
Name of the user to whom privileges are being granted. The user name must first have been introduced to the TimesTen database by a |
|
|
Specifies that the privilege is granted to all users. |
The following parameters are for granting object privileges:
| Parameter | Description |
|---|---|
|
|
This is the object privilege to grant. See "Object privileges" for a list of acceptable values. |
|
|
Assigns all object privileges to the user. |
|
|
|
|
|
Name of the user to whom privileges are being granted. The user must exist in the database. |
|
|
Specifies that the privilege is granted to all users. |
Description
-
One or more system privileges can be granted to a user by a user with
ADMINprivilege. -
One or more object privileges can be granted to a user by the owner of the object.
-
One or more object privileges can be granted to a user on any object by a user with
ADMINprivilege. -
To remove a privilege from a user, use the
REVOKEstatement. -
You cannot grant system privileges and object privileges in the same statement.
-
Only one object can be specified in an object privilege statement.
-
When replication is configured, this statement is replicated.
Examples
Grant the ADMIN privilege to the user terry:
GRANT admin TO terry;
Assuming the grantor has ADMIN privilege, grant the SELECT privilege to user terry on the customers table owned by user pat:
GRANT SELECT ON pat.customers TO terry;
Grant an object privilege to user terry:
GRANT SELECT ON emp_details_view TO terry;
See also
INSERT
The INSERT statement adds rows to a table.
The following expressions can be used in the VALUES clause of an INSERT statement:
-
Sequence
NEXTVALand SequenceCURRVAL -
DEFAULT
Required privilege
No privilege is required for the table owner.
INSERT for another user's table.
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
INSERT [hint] INTO [Owner.]TableName [(Column [,...])] VALUES (SingleRowValues) [RETURNING|RETURN Expression[,...] INTO DataItem[,...]]
The SingleRowValues parameter has the syntax:
{NULL|{?|:DynamicParameter}|{Constant}| DEFAULT}[,...]Parameters
| Parameter | Description |
|---|---|
|
|
Specifies a statement level optimizer hint for the |
|
|
The owner of the table into which data is inserted. |
|
|
Name of the table into which data is inserted. |
|
|
Each column in this list is assigned a value from If you omit one or more of the table's columns from this list, then the value of the omitted column in the inserted row is the column default value as specified when the table was created or last altered. If any omitted column has a If you omit a list of columns completely, then you must specify values for all columns in the table. |
|
: |
Placeholder for a dynamic parameter in a prepared SQL statement. The value of the dynamic parameter is supplied when the statement is executed. |
|
|
A specific value. See "Constants" for information on constants. |
|
|
Specifies that the column should be updated with the default value. |
|
|
Valid expression syntax. See Expressions for information on expressions. |
|
|
Host variable or PL/SQL variable that stores the retrieved |
Description
-
If you omit any of the table's columns from the column name list, the
INSERTstatement places the default value in the omitted columns. If the table definition specifiesNOT NULLfor any of the omitted columns and there is no default value, theINSERTstatement fails. -
BINARYandVARBINARYdata can be inserted in character or hexadecimal format:-
Character format requires single quotes.
-
Hexadecimal format requires the prefix
0xbefore the value.
-
-
The
INSERToperation fails if it violates a foreign key constraint. See "CREATE TABLE" for a description of the foreign key constraint. -
Restrictions on the
RETURNINGclause:-
Each
Expressionmust be a simple expression. Aggregate functions are not supported. -
You cannot return a sequence number into an
OUTparameter. -
ROWNUMand subqueries cannot be used in theRETURNINGclause. -
Parameters in the
RETURNINGclause cannot be duplicated anywhere in theINSERTstatement. -
In PL/SQL, you cannot use a
RETURNINGclause with aWHERE CURRENToperation.
-
Examples
A new single row is added to the purchasing.vendors table.
INSERT INTO purchasing.vendors VALUES (9016, 'Secure Systems, Inc.', 'Jane Secret', '454-255-2087', '1111 Encryption Way', 'Hush', 'MD', '00007', 'discount rates are secret');
For dynamic parameters :pno and :pname, values are supplied at runtime.
INSERT INTO purchasing.parts (partnumber, partname) VALUES (:pno, :pname);
Return the annual salary and job_id of a new employee. Declare the variables sal and jobid with the same data types as salary and job_id. Insert the row into employees. Print the variables for verification.
Command> VARIABLE sal12 NUMBER(8,2);
Command> VARIABLE jobid VARCHAR2(10) INLINE NOT NULL;
Command> INSERT INTO employees(employee_id, last_name, email, hire_date,
job_id, salary)
VALUES (211,'Doe','JDOE',sysdate,'ST_CLERK',2400)
RETURNING salary*12, job_id INTO :sal12,:jobid;
1 row inserted.
PRINT sal12 jobid;
SAL12 : 28800
JOBID : ST_CLERKSee also
INSERT...SELECT
The INSERT...SELECT statement inserts the results of a query into a table.
Required privilege
No privilege is required for the object owner.
INSERT and SELECT for another user's object.
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
INSERT INTO [Owner.]TableName [(ColumnName [,...])] InsertQuery
Parameters
| Parameter | Description |
|---|---|
|
|
Table to which data is to be added. |
|
|
Column for which values are supplied. If you omit any of the table's columns from the column name list, the |
|
|
Any supported |
Description
-
The column types of the result set must be compatible with the column types of the target table.
-
You can specify a sequence
CURRVALorNEXTVALwhen inserting values. See "Using CURRVAL and NEXTVAL in TimesTen Classic" for more details. -
In the
InsertQuery, theORDER BYclause is allowed. The sort order may be modified using theORDER BYclause when the result set is inserted into the target table, but the order is not guaranteed. -
The
INSERToperation fails if there is an error in theInsertQuery. -
A
RETURNINGclause cannot be used in anINSERT...SELECTstatement. -
The
SELECTsubquery in aUNION,UNIONALL,MINUS, orINTERSECTmust have the same number of projected expressions.
Examples
New rows are added to the purchasing.parts table that describe which parts are delivered in 20 days or less.
INSERT INTO purchasing.parts SELECT partnumber, deliverydays FROM purchasing.supplyprice WHERE deliverydays < 20;
LOAD CACHE GROUP
The LOAD CACHE GROUP statement loads data from Oracle database tables into a TimesTen cache group.
Required privilege
No privilege is required for the cache group owner.
LOAD or LOAD ANY CACHE GROUP for another user's cache group.
INSERT, DELETE, UPDATE privileges on underlying tables.
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
LOAD CACHE GROUP [Owner.]GroupName [WHERE ConditionalExpression] COMMIT EVERY n ROWS [PARALLEL NumThreads [READERS NumReaders]]
or
LOAD CACHE GROUP [Owner.]GroupName WITH ID (ColumnValueList)
Note:
TheWITH ID clause is not supported in TimesTen Scaleout.
Parameters
| Parameter | Description |
|---|---|
|
|
Name assigned to the cache group. |
|
|
Use the |
|
|
Use the
|
|
|
Provides parallel loading for cache group tables. Specifies the number of loading threads to run concurrently. One thread performs the bulk fetch from the Oracle database and the other threads ( The minimum value for |
|
|
This option specifies the total number of threads from the NumThreads parameter to use for bulk fetching from the Oracle database. For example, if you specify a NumThreads parameter of Express NumReaders as an integer where |
|
|
The The |
Description
-
LOAD CACHE GROUPloads all new cache instances from the Oracle database that satisfy the cache group definition and are not yet present in the cache group. -
Before issuing the
LOAD CACHE GROUPstatement, ensure that the replication agent is running if the cache group is replicated or is an AWT cache group. Make sure the cache agent is running. -
LOAD CACHE GROUPis executed in its own transaction, and must be the first operation in a transaction. -
LOAD CACHE GROUPonly loads new (inserted) rows on the Oracle database tables into the corresponding TimesTen cache tables. -
Errors cause a rollback. When cache instances are committed periodically, errors abort the remainder of the load. The load is rolled back to the last commit.
-
If the
LOAD CACHE GROUPstatement fails when you specifyCOMMIT EVERYnROWS(wheren>= 0), the content of the target cache group could be in an inconsistent state since some loaded rows are already committed. Some cache instances may be partially loaded. Use theUNLOAD CACHE GROUPstatement to unload the cache group, then reload the cache group. -
Generally, you do not have to fully qualify the column names in the
WHEREclause of theLOAD CACHE GROUPstatement. However, since TimesTen automatically generates queries that join multiple tables in the same cache group, a column must be fully qualified if there is more than one table in the cache group that contains columns with the same name. -
When loading a read-only cache group:
-
The
AUTOREFRESHstate must be paused. -
The
LOAD CACHE GROUPstatement cannot have aWHEREclause (except on a dynamic cache group). -
The cache group must be empty.
-
-
The automatic refresh state of a cache group may change after a
LOADCACHEGROUPoperation completes. See "Loading and refreshing a dynamic cache group with autorefresh" in the Oracle TimesTen In-Memory Database Cache Guide for information. -
Following the execution of a
LOAD CACHE GROUPstatement, the ODBC functionSQLRowCount(), the JDBC methodgetUpdateCount(), and the OCI functionOCIAttrGet()with theOCI_ATTR_ROW_COUNTargument return the number of cache instances that were loaded. -
Use the
WITH IDclause as follows:-
In place of the
WHEREclause for faster loading of the cache instance -
To specify binding parameters
-
To roll back the load transaction upon failure
-
Restrictions
-
The
LOADCACHEGROUP...WITHIDclause is not supported in TimesTen Scaleout.
-
Do not reference child tables in the
WHEREclause. -
Do not specify the
PARALLELclause in the following circumstances:-
With the
WITH IDclause -
With the
COMMIT EVERY 0 ROWSclause -
When database level locking is enabled (connection attribute
LockLevelis set to 1)
-
-
Do not use the
WITH IDclause when loading these types of cache groups:-
Static read-only cache group
-
Static user managed cache group with the autorefresh attribute
-
User managed cache group with the
AUTOREFRESHandPROPAGATEattributes
-
-
Do not use the
WITH IDclause with theCOMMIT EVERYnROWSclause.
Examples
CREATE CACHE GROUP recreation.cache FROM recreation.clubs ( clubname CHAR(15) NOT NULL, clubphone SMALLINT, activity CHAR(18), PRIMARY KEY(clubname)) WHERE (recreation.clubs.activity IS NOT NULL); LOAD CACHE GROUP recreation.cache COMMIT EVERY 30 ROWS;
Use the HR schema to illustrate the use of the PARALLEL clause with the LOAD CACHE GROUP statement. The COMMIT EVERY n ROWS clause is required. Issue the CACHEGROUPS command. You see cache group cg2 is defined and the autorefresh state is paused. Unload cache group cg2, then specify the LOAD CACHE GROUP statement with the PARALLEL clause to provide parallel loading. You see 25 cache instances loaded.
Command> CACHEGROUPS; Cache Group SAMPLEUSER.CG2: Cache Group Type: Read Only Autorefresh: Yes Autorefresh Mode: Incremental Autorefresh State: Paused Autorefresh Interval: 1.5 Minutes Root Table: SAMPLEUSER.COUNTRIES Table Type: Read Only Child Table: SAMPLEUSER.LOCATIONS Table Type: Read Only Child Table: SAMPLEUSER.DEPARTMENTS Table Type: Read Only 1 cache group found. Command> UNLOAD CACHE GROUP cg2; 25 cache instances affected. Command> COMMIT; Command> LOAD CACHE GROUP cg2 COMMIT EVERY 10 ROWS PARALLEL 2; 25 cache instances affected. Command> COMMIT;
The following example loads only the cache instances for customers whose customer number is greater than or equal to 5000 into the TimesTen cache tables in the new_customers cache group from the corresponding Oracle database tables:
LOAD CACHE GROUP new_customers WHERE (oratt.customer.cust_num >= 5000) COMMIT EVERY 256 ROWS;
See also
MERGE
This statement is not supported in TimesTen Scaleout.
In TimesTen Classic:
The MERGE statement enables you to select rows from one or more sources for update or insertion into a target table. You can specify conditions that are used to evaluate which rows are updated or inserted into the target table.
Use this statement to combine multiple INSERT and UPDATE statements.
MERGE is a deterministic statement: You cannot update the same row of the target table multiple times in the same MERGE statement.
Required privilege
No privilege is required for the owner of the target table and the source table.
INSERT or UPDATE on a target table owned by another user and SELECT on a source table owned by another user.
Usage with TimesTen Scaleout
This statement is not supported with TimesTen Scaleout.
SQL syntax
MERGE [hint] INTO [Owner.]TargetTableName [Alias] USING {[Owner.]SourceTableName|(Subquery)}[Alias] ON (Condtion) {MergeUpdateClause MergeInsertClause | MergeInsertClause MergeUpdateClause | MergeUpdateClause | MergeInsertClause }
The syntax for MergeUpdateClause is as follows:
WHEN MATCHED THEN UPDATE SET SetClause [WHERE Condition1]
The syntax for MergeInsertClause is as follows:
WHEN NOT MATCHED THEN INSERT [Columns [,...]] VALUES ( {{Expression | DEFAULT|NULL} [,...] }) [WHERE Condition2]
Parameters
| Parameter | Description |
|---|---|
|
|
Specifies a statement level optimizer hint for the |
|
|
Name of the target table. This is the table in which rows are either updated or inserted. |
|
|
You can optionally specify an alias name for the target or source table. |
|
|
The |
|
|
Specify the condition used to evaluate each row of the target table to determine if the row should be considered for either a merge insert or a merge update. If the condition is true when evaluated, then the |
|
|
Clause used with the |
|
|
For each row that matches the |
|
|
Columns to insert into the target table. See "INSERT" for information on the |
|
|
If specified, |
Description
-
You can specify the
MergeUpdateClauseandMergeInsertClausetogether or separately. If you specify both, they can be in either order. -
If
DUALis the only table specified in theUSINGclause and it is not referenced elsewhere in theMERGEstatement, specifyDUALas a simple table rather than using it in a subquery. In this simple case, to help performance, specify a key condition on a unique index of the target table in theONclause. -
Restrictions on the
MergeUpdateClause:-
You cannot update a column that is referenced in the
ONcondition clause. -
You cannot update source table columns.
-
-
Restrictions on the
MergeInsertClause:-
You cannot insert values of target table columns.
-
-
Other restrictions:
-
Do not use the set operators in the subquery of the source table.
-
Do not use a subquery in the
WHEREcondition of either theMergeUpdateClauseor theMergeInsertClause. -
The target table cannot be a detail table of a materialized view.
-
The
RETURNINGclause cannot be used in aMERGEstatement.
-
Examples
In this example, dual is specified as a simple table. There is a key condition on the UNIQUE index of the target table specified in the ON clause. The DuplicateBindMode attribute is set to 1 in this example. (The default is 0.)
Command> CREATE TABLE mergedualex (col1 TT_INTEGER NOT NULL, col2 TT_INTEGER, PRIMARY KEY (col1)); Command> MERGE INTO mergedualex USING dual ON (col1 = :v1) WHEN MATCHED THEN UPDATE SET col2 = col2 + 1 WHEN NOT MATCHED THEN INSERT VALUES (:v1, 1); Type '?' for help on entering parameter values. Type '*' to end prompting and abort the command. Type '-' to leave the parameter unbound. Type '/;' to leave the remaining parameters unbound and execute the command. Enter Parameter 1 'V1' (TT_INTEGER) > 10 1 row merged. Command> SELECT * FROM mergedualex; < 10, 1 > 1 row found.
In this example, a table called contacts is created with columns employee_id and manager_id. One row is inserted into contacts with values 101 and NULL for employee_id and manager_id, respectively. The MERGE statement is used to insert rows into contacts using the data in the employees table. A SELECT FIRST 3 rows is used to illustrate that in the case where employee_id is equal to 101, manager_id is updated to 100. The remaining 106 rows from the employees table are inserted into contacts:
Command> CREATE TABLE contacts (employee_id NUMBER (6) NOT NULL PRIMARY KEY,
manager_id NUMBER (6));
Command> SELECT employee_id, manager_id FROM employees WHERE employee_id =101;
< 101, 100 >
1 row found.
Command> INSERT INTO contacts VALUES (101,null);
1 row inserted.
Command> SELECT COUNT (*) FROM employees;
< 107 >
1 row found.
Command> MERGE INTO contacts c
USING employees e
ON (c.employee_id = e.employee_id)
WHEN MATCHED THEN
UPDATE SET c.manager_id = e.manager_id
WHEN NOT MATCHED THEN
INSERT (employee_id, manager_id)
VALUES (e.employee_id, e.manager_id);
107 rows merged.
Command> SELECT COUNT (*) FROM contacts;
< 107 >
1 row found.
Command> SELECT FIRST 3 employee_id,manager_id FROM employees;
< 100, <NULL> >
< 101, 100 >
< 102, 100 >
3 rows found.
Command> SELECT FIRST 3 employee_id, manager_id FROM contacts;
< 100, <NULL> >
< 101, 100 >
< 102, 100 >
3 rows found.REFRESH CACHE GROUP
The REFRESH CACHE GROUP statement replaces data in the TimesTen cache tables with the most current committed data from the Oracle database cached tables.
Required privilege
CREATE SESSION on the Oracle Database schema and SELECT on the Oracle Database tables.
No privilege for the cache group is required for the cache group owner.
REFRESH or REFRESH ANY CACHE GROUP for another user's cache group.
INSERT, DELETE, UPDATE privileges on underlying tables.
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
REFRESH CACHE GROUP [Owner.]GroupName [WHERE ConditionalExpression] COMMIT EVERY n ROWS [PARALLEL NumThreads]
or
REFRESH CACHE GROUP [Owner.]GroupName WITH ID (ColumnValueList)
Note:
TheWITH ID clause is not supported in TimesTen Scaleout.
Parameters
| Parameter | Description |
|---|---|
|
|
Name assigned to the cache group. |
|
|
Use the |
|
|
Use the
|
|
|
Provides parallel loading for cache group tables. Specifies the number of loading threads to run concurrently. One thread performs the bulk fetch from the Oracle database and the other threads ( The minimum value for |
|
|
The The |
Description
-
A
REFRESH CACHE GROUPstatement must be executed in its own transaction. -
Before issuing the
REFRESH CACHE GROUPstatement, ensure that the replication agent is running if the cache group is replicated or is an AWT cache group. Make sure the cache agent is running. -
The
REFRESHCACHEGROUPstatement replaces data in the TimesTen cached tables with the most current committed data from the cached Oracle database tables, including data that already exists in the TimesTen cached tables. For an explicitly loaded cache group, a refresh operation is equivalent to issuing anUNLOAD CACHE GROUPstatement followed by aLOAD CACHE GROUPstatement. Operations on all rows in the Oracle database tables including inserts, updates, and deletes are applied to the cache tables. For dynamic cache groups, a refresh operation refreshes only rows that are updated or deleted on the Oracle database tables into the cache tables. For more information on explicitly loaded and dynamic cache groups, see "Transmitting changes between the TimesTen and Oracle databases" in Oracle TimesTen In-Memory Database Cache Guide. -
When refreshing a read-only cache group:
-
The
AUTOREFRESHstate must be paused. -
If the cache group is a read-only dynamic cache group, do not use the
PARALLELclause.
-
-
If the automatic refresh state of a cache group (dynamic or explicitly loaded) is
PAUSED, the state is changed toONafter an unconditionalREFRESH CACHE GROUPstatement issued on the cache group completes. -
If the automatic refresh state of a dynamic cache group is
PAUSED, the state remainsPAUSEDafter aREFRESH CACHE GROUP...WITH IDstatement completes. -
Generally, you do not have to fully qualify the column names in the
WHEREclause of theREFRESH CACHE GROUPstatement. However, since TimesTen automatically generates queries that join multiple tables in the same cache group, a column must be fully qualified if there is more than one table in the cache group that contains columns with the same name. -
If the
REFRESH CACHE GROUPstatement fails when you specifyCOMMIT EVERYnROWS(wheren>= 0), the content of the target cache group could be in an inconsistent state since some loaded rows are already committed. Some cache instances may be partially loaded. Use theUNLOAD CACHE GROUPstatement to unload the cache group, then use theLOAD CACHE GROUPstatement to reload the cache group. -
Following the execution of a
REFRESH CACHE GROUPstatement, the ODBC functionSQLRowCount(), the JDBC methodgetUpdateCount(), and the OCI functionOCIAttrGet()with theOCI_ATTR_ROW_COUNTargument return the number of cache instances that were refreshed. -
Use the
WITH IDclause:-
In place of the
WHEREclause for faster refreshing of the cache instance -
To specify binding parameters
-
To roll back the refresh transaction upon failure
-
Restrictions
-
The
REFRESHCACHEGROUP...WITHIDclause is not supported in TimesTen Scaleout. -
Do not specify the
PARALLELclause:-
With the
WITH IDclause -
With the
COMMITEVERYnROWSclause -
When database level locking is enabled (connection attribute
LockLevelis set to 1) -
For read-only dynamic cache groups
-
-
Do not use the
WITH IDclause when refreshing these types of cache groups:-
Static read-only cache groups
-
Static user managed cache groups with the autorefresh attribute
-
User managed cache groups with the autorefresh and propagate attributes
-
-
Do not use the
WITH IDclause with theCOMMIT EVERYnROWSclause. -
Do not use the
WHEREclause with dynamic or read-only cache groups.
Examples
REFRESH CACHE GROUP recreation.cache COMMIT EVERY 30 ROWS;
Is equivalent to:
UNLOAD CACHE GROUP recreation.cache; LOAD CACHE GROUP recreation.cache COMMIT EVERY 30 ROWS;
Use the HR schema to illustrate the use of the PARALLEL clause with the REFRESH CACHE GROUP statement. The COMMIT EVERY n ROWS is required. Issue the CACHEGROUPS command. You see cache group cg2 is defined and the autorefresh state is paused. Specify the REFRESH CACHE GROUP statement with the PARALLEL clause to provide parallel loading. You see 25 cache instances refreshed.
Command> CACHEGROUPS; Cache Group SAMPLEUSER.CG2: Cache Group Type: Read Only Autorefresh: Yes Autorefresh Mode: Incremental Autorefresh State: Paused Autorefresh Interval: 1.5 Minutes Root Table: SAMPLEUSER.COUNTRIES Table Type: Read Only Child Table: SAMPLEUSER.LOCATIONS Table Type: Read Only Child Table: SAMPLEUSER.DEPARTMENTS Table Type: Read Only 1 cache group found. Command> REFRESH CACHE GROUP cg2 COMMIT EVERY 20 ROWS PARALLEL 2; 25 cache instances affected.
REVOKE
The REVOKE statement removes one or more privileges from a user.
Required privilege
ADMIN to revoke system privileges.
ADMIN or object owner to revoke object privileges.
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
REVOKE {SystemPrivilege [,...] | ALL [PRIVILEGES]} FROM {User |PUBLIC} [,...]or
REVOKE {{ObjectPrivilege [,...] | ALL [PRIVILEGES]} ON {[Owner.Object}} [,...]
FROM {user | PUBLIC}[,...]Parameters
The following parameters are for revoking system privileges:
| Parameter | Description |
|---|---|
|
|
This is the system privilege to revoke. See "System privileges" for a list of acceptable values. |
|
|
Revokes all system privileges from the user. |
|
|
Name of the user from whom privileges are being revoked. The user name must first have been introduced to the TimesTen database by a |
|
|
Specifies that the privilege is revoked for all users. |
The following parameters are for revoking object privileges:
| Parameter | Description |
|---|---|
|
|
This is the object privilege to revoke. See "Object privileges" for a list of acceptable values. |
|
|
Revokes all object privileges from the user. |
|
|
Name of the user from whom privileges are to be revoked. The user name must first have been introduced to the TimesTen database through a |
|
|
|
|
|
Specifies that the privilege is revoked for all users. |
Description
-
Privileges on objects cannot be revoked from the owner of the objects.
-
Any user who can grant a privilege can revoke the privilege even if they were not the user who originally granted the privilege.
-
Privileges must be revoked at the same level they were granted. You cannot revoke an object privilege from a user who has the associated system privilege. For example, if you grant
SELECT ANY TABLEto a user and then try to revokeSELECT ON BOB.TABLE1, the revoke fails unless you have specifically grantedSELECT ON BOB.TABLE1in addition toSELECT ANY TABLE. -
If a user has been granted all system privileges, you can revoke a specific privilege. For example, you can revoke
ALTER ANY TABLEfrom a user who has been granted all system privileges. -
If a user has been granted all object privileges, you can revoke a specific privilege on a specific object from the user. For example, you can revoke the
DELETEprivilege on tableCUSTOMERSfrom userTERRYeven ifTERRYhas previously been granted all object privileges. -
You can revoke all privileges from a user even if the user has not previously been granted all privileges.
-
You cannot revoke a specific privilege from a user who has not been granted the privilege.
-
You cannot revoke privileges on objects owned by a user.
-
You cannot revoke system privileges and object privileges in the same statement.
-
You can specify only one object in an object privilege statement.
-
Revoking the
SELECTprivilege on a detail table or a system privilege that includes theSELECTprivilege fromuser2on a detail table owned byuser1causes associated materialized views owned byuser2to be marked invalid. -
When replication is configured, this statement is replicated.
Examples
Revoke the ADMIN and DDL privileges from the user terry:
REVOKE admin, ddl FROM terry;
Assuming the revoker has ADMIN privilege, revoke the UPDATE privilege from terry on the customers table owned by pat:
REVOKE update ON pat.customers FROM terry;
See also
ROLLBACK
Use the ROLLBACK statement to undo work done in the current transaction.
Required privilege
None
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
ROLLBACK [WORK]
Parameters
The ROLLBACK statement enables the following optional keyword:
| Parameter | Description |
|---|---|
|
|
Optional clause supported for compliance with the SQL standard. |
Description
When the PassThrough connection attribute is specified with a value greater than zero, the Oracle database transaction will also be rolled back.
A rollback closes all open cursors.
Examples
Insert a row into the regions table of the HR schema and then roll back the transaction. First set AUTOCOMMIT to 0:
Command> SET AUTOCOMMIT 0; Command> INSERT INTO regions VALUES (5,'Australia'); 1 row inserted. Command> SELECT * FROM regions; < 1, Europe > < 2, Americas > < 3, Asia > < 4, Middle East and Africa > < 5, Australia > 5 rows found. Command> ROLLBACK; Command> SELECT * FROM regions; < 1, Europe > < 2, Americas > < 3, Asia > < 4, Middle East and Africa > 4 rows found.
See also
SELECT
The SELECT statement retrieves data from one or more tables. The retrieved data is presented in the form of a table that is called the result table, result set, or query result.
Required privilege
No privilege is required for the object owner.
SELECT for another user's object.
SELECT...FOR UPDATE also requires UPDATE privilege for another user's object.
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
The general syntax for a SELECT statement is the following:
[WithClause] SELECT [hint][FIRST NumRows | ROWS m TO n] [ALL | DISTINCT] SelectList FROM TableSpec [,...] [WHERE SearchCondition] [GROUP BY GroupByClause [,...] [HAVING SearchCondition]] [ORDER BY OrderByClause [,...]] [FOR UPDATE [OF [[Owner.]TableName.]ColumnName [,...]] [NOWAIT | WAIT Seconds]]
The syntax for a SELECT statement that contains the set operators UNION, UNION ALL, MINUS, or INTERSECT is as follows:
SELECT [hint] [ROWS m TO n] [ALL] SelectList FROM TableSpec [,...] [WHERE SearchCondition] [GROUP BY GroupByClause [,...] [HAVING SearchCondition] [,...]] {UNION [ALL] | MINUS | INTERSECT} SELECT [ROWS m TO n] [ALL] SelectList FROM TableSpec [,...] [WHERE SearchCondition] [GROUP BY GroupByClause [,...] [HAVING SearchCondition [,...] ] ] [ORDER BY OrderByClause [,...] ]
The syntax for OrderByClause is as follows:
{ColumnID|ColumnAlias|Expression} [ASC|DESC] [NULLS { FIRST|LAST }]Parameters
| Parameter | Description |
|---|---|
|
|
The |
|
|
Specifies a statement level optimizer hint for the |
|
|
Specifies the number of rows to retrieve. |
|
|
Specifies the range of rows to retrieve where Use either a positive |
|
|
Prevents elimination of duplicate rows from the query result. If neither |
|
|
Ensures that each row in the query result is unique. All You cannot use |
|
|
Specifies how the columns of the query result are to be derived. See "SelectList" for the syntax for a select list. |
|
|
Identifies the tables referenced in the
|
|
|
The The unary (+) operator may follow some column and See "Search Conditions" for more information on search conditions. |
|
|
The |
|
|
The Subqueries can be specified in the |
|
|
A simple join (also called an inner join) returns a row for each pair of rows from the joined tables that satisfy the join condition specified in |
|
|
Sorts the query result rows in order by specified columns or expressions. Specify the sort key columns in order from major sort key to minor sort key. The |
|
|
Must correspond to a column in the select list. You can identify a column to be sorted by specifying its name or its ordinal number. The first column in the select list is column number 1. It is better to use a column number when referring to columns in the select list if they are not simple columns. Some examples are aggregate functions, arithmetic expressions, and constants. A
|
|
|
Used in an
|
|
|
For each column designated in the |
|
|
Valid with Specify If you specify the |
|
|
|
|
|
Specifies that the results of The The The The data type of corresponding selected entries in both The length of a column in the result is the longer length of correspondent selected values for the column. The column names of the final result are the column names of the leftmost select. You can combine multiple queries using the set operators One or both operands of a set operator can be a set operator. Multiple or nested set operators are evaluated from left to right. The set operators can be mixed in the same query. Restrictions on the
|
Description
-
When you use a correlation name, the correlation name must conform to the syntax rules for a basic name. All correlation names within one
SELECTstatement must be unique. Correlation names are useful when you join a table to itself. Define multiple correlation names for the table in theFROMclause and use the correlation names in the select list and theWHEREclause to qualify columns from that table. See "TableSpec" for more information about correlation names. -
SELECT...FOR UPDATEis supported in aSELECTstatement that specifies a subquery, but it can be specified only in the outermost query. -
If your query specifies either
FIRSTNumRowsorROWSmTOn,ROWNUMmay not be used to restrict the number of rows returned. -
FIRSTNumRowsandROWSmTOncannot be used together in the sameSELECTstatement. -
Use the
SELECT...INTOstatement in PL/SQL. If you use theSELECT...INTOstatement outside of PL/SQL, TimesTen accepts, but silently ignores, the syntax.
Examples
This example shows the use of a column alias (max_salary) in the SELECT statement:
SELECT MAX(salary) AS max_salary FROM employees WHERE employees.hire_date > '2000-01-01 00:00:00'; < 10500 > 1 row found.
This example uses two tables, orders and lineitems.
The orders table and lineitems table are created as follows:
CREATE TABLE orders(orderno INTEGER, orderdate DATE, customer CHAR(20)); CREATE TABLE lineitems(orderno INTEGER, lineno INTEGER, qty INTEGER, unitprice DECIMAL(10,2));
Thus for each order, there is one record in the orders table and a record for each line of the order in lineitems.
To find the total value of all orders entered since the beginning of the year, use the HAVING clause to select only those orders that were entered on or after January 1, 2000:
SELECT o.orderno, customer, orderdate, SUM(qty * unitprice) FROM orders o, lineitems l WHERE o.orderno=l.orderno GROUP BY o.orderno, customer, orderdate HAVING orderdate >= DATE '2000-01-01';
Consider this query:
SELECT * FROM tablea, tableb WHERE tablea.column1 = tableb.column1 AND tableb.column2 > 5 FOR UPDATE;
The query locks all rows in tablea where:
-
The value of
tablea.column1equals at least onetableb.column1value wheretableb.column2is greater than 5.
The query also locks all rows in tableb where:
-
The value of
tableb.column2is greater than 5. -
The value of
tableb.column1equals at least onetablea.column1value.
If no WHERE clause is specified, all rows in both tables are locked.
This example demonstrates the (+) join operator:
SELECT * FROM t1, t2 WHERE t1.x = t2.x(+);
The following query returns an error because an outer join condition cannot be connected by OR.
SELECT * FROM t1, t2, t3 WHERE t1.x = t2.x(+) OR t3.y = 5;
The following query is valid:
SELECT * FROM t1, t2, t3 WHERE t1.x = t2.x(+) AND (t3.y = 4 OR t3.y = 5);
A condition cannot use the IN operator to compare a column marked with (+). For example, the following query returns an error.
SELECT * FROM t1, t2, t3 WHERE t1.x = t2.x(+) AND t2.y(+) IN (4,5);
The following query is valid:
SELECT * FROM t1, t2, t3 WHERE t1.x = t2.x(+) AND t1.y IN (4,5);
The following query results in an inner join. The condition without the (+) operator is treated as an inner join condition.
SELECT * FROM t1, t2 WHERE t1.x = t2.x(+) AND t1.y = t2.y;
In the following query, the WHERE clause contains a condition that compares an inner table column of an outer join with a constant. The (+) operator is not specified and hence the condition is treated as an inner join condition.
SELECT * FROM t1, t2 WHERE t1.x = t2.x(+) AND t2.y = 3;
For more join examples, see "JoinedTable".
The following example returns the current sequence value in the student table.
SELECT SEQ.CURRVAL FROM student;
The following query produces a derived table because it contains a SELECT statement in the FROM clause.
SELECT * FROM t1, (SELECT MAX(x2) maxx2 FROM t2) tab2 WHERE t1.x1 = tab2.maxx2;
The following query joins the results of two SELECT statements.
SELECT * FROM t1 WHERE x1 IN (SELECT x2 FROM t2) UNION SELECT * FROM t1 WHERE x1 IN (SELECT x3 FROM t3);
In the following, select all orders that have the same price as the highest price in their category.
SELECT * FROM orders WHERE price = (SELECT MAX(price) FROM stock WHERE stock.cat=orders.cat);
The next example illustrates the use of the INTERSECT set operator. There is a department_id value in the employees table that is NULL. In the departments table, the department_id is defined as a NOT NULL primary key. The rows returned from using the INTERSECT set operator do not include the row in the departments table whose department_id value is NULL.
Command> SELECT department_id FROM employees INTERSECT SELECT department_id
FROM departments;
< 10 >
< 20 >
< 30 >
< 40 >
< 50 >
< 60 >
< 70 >
< 80 >
< 90 >
< 100 >
< 110 >
11 rows found.
Command> SELECT DISTINCT department_id FROM employees;
< 10 >
< 20 >
< 30 >
< 40 >
< 50 >
< 60 >
< 70 >
< 80 >
< 90 >
< 100 >
< 110 >
< <NULL> >
12 rows found.
The next example illustrates the use of the MINUS set operator by combining rows returned by the first query but not the second. The row containing the NULL department_id value in the employees table is the only row returned.
Command> SELECT department_id FROM employees
MINUS SELECT department_id FROM departments;
< <NULL> >
1 row found.
The following example illustrates the use of the SUBSTR expression in a GROUP BY clause and the use of a subquery in a HAVING clause. The first 10 rows are returned.
Command> SELECT ROWS 1 TO 10 SUBSTR (job_id, 4,10), department_id, manager_id,
SUM (salary) FROM employees
GROUP BY SUBSTR (job_id,4,10),department_id, manager_id
HAVING (department_id, manager_id) IN
(SELECT department_id, manager_id FROM employees x
WHERE x.department_id = employees.department_id)
ORDER BY SUBSTR (job_id, 4,10),department_id,manager_id;
< ACCOUNT, 100, 108, 39600 >
< ACCOUNT, 110, 205, 8300 >
< ASST, 10, 101, 4400 >
< CLERK, 30, 114, 13900 >
< CLERK, 50, 120, 22100 >
< CLERK, 50, 121, 25400 >
< CLERK, 50, 122, 23600 >
< CLERK, 50, 123, 25900 >
< CLERK, 50, 124, 23000 >
< MAN, 20, 100, 13000 >
10 rows found.
The following example locks the employees table for update and waits 10 seconds for the lock to be available. An error is returned if the lock is not acquired in 10 seconds. The first five rows are selected.
Command> SELECT FIRST 5 last_name FROM employees FOR UPDATE WAIT 10; < King > < Kochhar > < De Haan > < Hunold > < Ernst > 5 rows found.
The next example locks the departments table for update. If the selected rows are locked by another process, an error is returned if the lock is not available. This is because NOWAIT is specified.
Command> SELECT FIRST 5 last_name e FROM employees e, departments d
WHERE e.department_id = d.department_id
FOR UPDATE OF d.department_id NOWAIT;
< Whalen >
< Hartstein >
< Fay >
< Raphaely >
< Khoo >
5 rows found.
In the following, use the HR schema to illustrate the use of a subquery with the FOR UPDATE clause.
Command> SELECT employee_id, job_id FROM job_history
WHERE (employee_id, job_id) NOT IN (SELECT employee_id, job_id
FROM employees)
FOR UPDATE;
< 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.
In the following, use a dynamic parameter placeholder for SELECT ROWS m TO n and SELECT FIRST.
Command> SELECT ROWS ? TO ? employee_id FROM employees; Type '?' for help on entering parameter values. Type '*' to end prompting and abort the command. Type '-' to leave the parameter unbound. Type '/;' to leave the remaining parameters unbound and execute the command. Enter Parameter 1 (TT_INTEGER) > 1 Enter Parameter 2 (TT_INTEGER) > 3 < 100 > < 101 > < 102 > 3 rows found. Command> SELECT ROWS :a TO :b employee_id FROM employees; Type '?' for help on entering parameter values. Type '*' to end prompting and abort the command. Type '-' to leave the parameter unbound. Type '/;' to leave the remaining parameters unbound and execute the command. Enter Parameter 1 (TT_INTEGER) > 1 Enter Parameter 2 (TT_INTEGER) > 3 < 100 > < 101 > < 102 > 3 rows found. Command> SELECT FIRST ? employee_id FROM employees; Type '?' for help on entering parameter values. Type '*' to end prompting and abort the command. Type '-' to leave the parameter unbound. Type '/;' to leave the remaining parameters unbound and execute the command. Enter Parameter 1 (TT_INTEGER) > 3 < 100 > < 101 > < 102 > 3 rows found.
The following example illustrates the use of NULLS LAST in the ORDER BY clause. Query the employees table to find employees with a commission percentage greater than .30 or a commission percentage that is NULL. Select the first seven employees and order by commission_pct and last_name. Order commision_pct in descending order and use NULLS LAST to display rows with NULL values last in the query. Output commission_pct and last_name.
Command> SELECT FIRST 7 commission_pct,last_name
FROM employees where commission_pct > .30
OR commission_pct IS NULL
ORDER BY commission_pct DESC NULLS LAST,last_name;
< .4, Russell >
< .35, King >
< .35, McEwen >
< .35, Sully >
< <NULL>, Atkinson >
< <NULL>, Austin >
< <NULL>, Baer >
7 rows found.WithClause
Syntax
WithClause has the following syntax:
WITHQueryNameAS (Subquery) [,QueryNameAS (Subquery)] ...
Parameters
WithClause has the following parameter:
| Parameter | Description |
|---|---|
|
|
Specifies an alias for a subquery that can be used multiple times within the |
Description
Subquery factoring provides the WITH clause that enables you to assign a name to a subquery block, which can subsequently be referenced multiple times within the main SELECT query. The query name is visible to the main query and any subquery contained in the main query.
The WITH clause can only be defined as a prefix to the main SELECT statement.
Subquery factoring is useful in simplifying complex queries that use duplicate or complex subquery blocks in one or more places. In addition, TimesTen uses subquery factoring to optimize the query by evaluating and materializing the subquery block once and providing the result for each reference in the SELECT statement.
You can specify the set operators: UNION, MINUS, INTERSECT in the main query.
Restrictions using the WITH clause:
-
Do not use the
WITHclause in a view or materialized view definition. -
Recursive subquery factoring is not supported.
-
Do not use the
WITHclause in subqueries or derived tables. -
You cannot provide a column parameter list for the query alias. For example, TimesTen does not support:
WITHw1(c1,c2)AS...
Example
The following example creates the query names dept_costs and avg_cost for the initial query block, then uses these names in the body of the main query.
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;
> DEPARTMENT_NAME DEPT_TOTAL
-------------------------------
Sales 304500
Shipping 156400SelectList
SQL syntax
The SelectList parameter of the SELECT statement has the following syntax:
{* | [Owner.]TableName.* |
{ Expression | [[Owner.]TableName.]ColumnName |
[[Owner.]TableName.]ROWID | NULL
}
[[AS] ColumnAlias] } [,...]Parameters
The SelectList parameter of the SELECT statement has the following parameters:
| Parameter | Description |
|---|---|
|
|
Includes, as columns of the query result, all columns of all tables specified in the |
|
|
Includes all columns of the specified table in the result. |
|
|
An aggregate query includes a When the select list is not an aggregate query, the column reference must reference a table in the A column reference in the select list of an aggregate query must reference a column list in the |
|
|
Includes a particular column from the named owner's indicated table. You can also specify the |
|
|
Includes the |
|
|
When |
|
|
Used in an
|
Description
-
The clauses must be specified in the order given in the syntax.
-
TimesTen does not support subqueries in the select list.
-
A result column in the select list can be derived in any of the following ways.
-
A result column can be taken directly from one of the tables listed in the
FROMclause. -
Values in a result column can be computed, using an arithmetic expression, from values in a specified column of a table listed in the
FROMclause. -
Values in several columns of a single table can be combined in an arithmetic expression to produce the result column values.
-
Aggregate functions (
AVG,MAX,MIN,SUM, andCOUNT) can be used to compute result column values over groups of rows. Aggregate functions can be used alone or in an expression. You can specify aggregate functions containing theDISTINCTqualifier that operate on different columns in the same table. If theGROUP BYclause is not specified, the function is applied over all rows that satisfy the query. If theGROUP BYclause is specified, the function is applied once for each group defined by theGROUP BYclause. When you use aggregate functions with theGROUP BYclause, the select list can contain aggregate functions, arithmetic expressions, and columns in theGROUP BYclause. See "GROUP BY clause" for details on theGROUP BYclause. -
A result column containing a fixed value can be created by specifying a constant or an expression involving only constants.
-
-
In addition to specifying how the result columns are derived, the select list also controls their relative position from left to right in the query result. The first result column specified by the select list becomes the leftmost column in the query result, and so on.
-
Result columns in the select list are numbered from left to right. The leftmost column is number 1. Result columns can be referred to by column number in the
ORDER BYclause. This is especially useful to refer to a column defined by an arithmetic expression or an aggregate. -
To join a table with itself, define multiple correlation names for the table in the
FROMclause and use the correlation names in the select list and theWHEREclause to qualify columns from that table. -
When you use the
GROUP BYclause, one answer is returned per group in accordance with the select list, as follows:-
The
WHEREclause eliminates rows before groups are formed. -
The
GROUP BYclause groups the resulting rows. See "GROUP BY clause" for more details. -
The select list aggregate functions are computed for each group.
-
Examples
In the following example, one value, the average number of days you wait for a part, is returned:
SELECT AVG(deliverydays) FROM purchasing.supplyprice;
The part number and delivery time for all parts that take fewer than 20 days to deliver are returned by the following statement.
SELECT partnumber, deliverydays FROM purchasing.supplyprice WHERE deliverydays < 20;
Multiple rows may be returned for a single part.
The part number and average price of each part are returned by the following statement.
SELECT partnumber, AVG(unitprice) FROM purchasing.supplyprice GROUP BY partnumber;
In the following example, the join returns names and locations of California suppliers. Rows are returned in ascending order by partnumber values. Rows containing duplicate part numbers are returned in ascending order by vendorname values. The FROM clause defines two correlation names (v and s), which are used in both the select list and the WHERE clause. The vendornumber column is the only common column between vendors and supplyprice.
SELECT partnumber, vendorname, s.vendornumber,vendorcity FROM purchasing.supplyprice s, purchasing.vendors v WHERE s.vendornumber = v.vendornumber AND vendorstate = 'CA' ORDER BY partnumber, vendorname;
The following query joins table purchasing.parts to itself to determine which parts have the same sales price as the part whose serial number is '1133-P-01'.
SELECT q.partnumber, q.salesprice FROM purchasing.parts p, purchasing.parts q WHERE p.salesprice = q.salesprice AND p.serialnumber = '1133-P-01';
The next example shows how to retrieve the rowid of a specific row. The retrieved rowid value can be used later for another SELECT, DELETE, or UPDATE statement.
SELECT rowid FROM purchasing.vendors WHERE vendornumber = 123;
The following example shows how to use a column alias to retrieve data from the table employees.
SELECT MAX(salary) AS max_salary FROM employees;
TableSpec
SQL syntax
The TableSpec parameter of the SELECT statement has the following syntax:
TableNameSyntax | JoinedTable | DerivedTable TableNameSyntax::= [Owner.]TableName [CorrelationName] | ([Owner.]TableName) [CorrelationName] | ([Owner.]TableName [CorrelationName])
A simple table specification has the following syntax:
[Owner.]TableName or ([Owner.]TableName)
Parameters
The TableSpec parameter of the SELECT statement has the following parameters:
| Parameter | Description |
|---|---|
|
|
Identifies a table to be referenced. Parentheses are optional. |
|
|
All correlation names within one statement must be unique. |
|
|
Specifies the query that defines the table join. See "JoinedTable" for more information. |
|
|
Specifies a table derived from the evaluation of a |
JoinedTable
The JoinedTable parameter specifies a table derived from CROSS JOIN, INNER JOIN, LEFT OUTER JOIN or RIGHT OUTER JOIN.
SQL syntax
The syntax for JoinedTable is as follows:
{CrossJoin | QualifiedJoin}
Where CrossJoin is:
TableSpec1 CROSS JOIN TableSpec2
And QualifiedJoin is:
TableSpec1 [JoinType] JOIN TableSpec2 ON SearchCondition
In the QualifiedJoin parameter, JoinType syntax is as follows:
{INNER | LEFT [OUTER] | RIGHT [OUTER]}Parameters
The JoinedTable parameter of the TableSpec clause of a SELECT statement has the following parameters:
| Parameter | Description |
|---|---|
|
|
Performs a cross join on two tables. A cross join returns a result table that is the cartesian product of the input tables. The result is the same as that of a query with the following syntax:
|
|
|
Specifies that the join is of type |
|
|
Specifies the first table of the |
|
|
Specifies the second table of the |
|
|
Specifies the type of join to perform. These are the supported join types:
|
|
|
Specifies the search criteria to be used in a |
Description
-
FULL OUTER JOINis not supported. -
A joined table can be used to replace a table in a
FROMclause anywhere except in a statement that defines a materialized view. Thus, a joined table can be used inUNION,MINUS,INTERSECT, a subquery, a nonmaterialized view, or a derived table. -
A subquery cannot be specified in the operand of a joined table. For example, the following statement is not supported:
SELECT * FROM regions INNER JOIN (SELECT * FROM countries) table2 ON regions.region_id=table2.region_id;
-
A view can be specified as an operand of a joined table.
-
A temporary table cannot be specified as an operand of a joined table.
-
OUTER JOINcan be specified in two ways, either using the (+) operator inSearchConditionof theWHEREclause or using aJOINtable operation. The two specification methods cannot coexist in the same statement. -
Join order and grouping can be specified with a
JoinedTableoperation, but they cannot be specified with the (+) operator. For example, the following operation cannot be specified with the (+) operator:t LEFT JOIN (t2 INNER JOIN t3 ON x2=x3) ON (x1 = x2 - x3)
Examples
These examples use the regions and countries tables from the HR schema.
The following performs a left outer join.
SELECT * FROM regions LEFT JOIN countries ON regions.region_id=countries.region_id WHERE regions.region_id=3; < 3, Asia, JP, Japan, 3 > < 3, Asia, CN, China, 3 > < 3, Asia, IN, India, 3 > < 3, Asia, AU, Australia, 3 > < 3, Asia, SG, Singapore, 3 > < 3, Asia, HK, HongKong, 3 > 6 rows found.
You can also perform a left outer join with the (+) operator, as follows.
SELECT * FROM regions, countries
WHERE regions.region_id=countries.region_id (+)
AND regions.region_id=3;The following performs a right outer join.
SELECT * FROM regions RIGHT JOIN countries ON regions.region_id=wountries.region_id WHERE regions.region_id=3; < AU, Australia, 3, 3, Asia > < CN, China, 3, 3, Asia > < HK, HongKong, 3, 3, Asia > < IN, India, 3, 3, Asia > < JP, Japan, 3, 3, Asia > < SG, Singapore, 3, 3, Asia > 6 rows found.
The next example performs a right outer join with the (+) operator.
SELECT * FROM countries, regions
WHERE regions.region_id (+)=countries.region_id
AND countries.region_id=3;
< JP, Japan, 3, 3, Asia >
< CN, China, 3, 3, Asia >
< IN, India, 3, 3, Asia >
< AU, Australia, 3, 3, Asia >
< SG, Singapore, 3, 3, Asia >
< HK, HongKong, 3, 3, Asia >
6 rows found.Note that the right join methods produce the same rows but in a different display order. There should be no expectation of row order for join results.
The following performs an inner join.
SELECT * FROM regions INNER JOIN countries ON regions.region_id=countries.region_id WHERE regions.region_id=2; < 2, Americas, US, United States of America, 2 > < 2, Americas, CA, Canada, 2 > < 2, Americas, BR, Brazil, 2 > < 2, Americas, MX, Mexico, 2 > < 2, Americas, AR, Argentina, 2 > 5 rows found.
The next example performs a cross join.
SELECT * FROM regions CROSS JOIN countries WHERE regions.region_id=1; < 1, Europe, AR, Argentina, 2 > < 1, Europe, AU, Australia, 3 > < 1, Europe, BE, Belgium, 1 > < 1, Europe, BR, Brazil, 2 > ... < 1, Europe, SG, Singapore, 3 > < 1, Europe, UK, United Kingdom, 1 > < 1, Europe, US, United States of America, 2 > < 1, Europe, ZM, Zambia, 4 > < 1, Europe, ZW, Zimbabwe, 4 > 25 rows found.
See also
DerivedTable
A derived table is the result of a SELECT statement in the FROM clause, with an alias.
SQL syntax
The syntax for DerivedTable is as follows:
(Subquery) [CorrelationName]
Parameters
The DerivedTable parameter of the TableSpec clause of a SELECT statement has the following parameters:
| Parameter | Description |
|---|---|
|
|
See "Subqueries" for information on subqueries. |
|
|
Optionally use |
Description
When using a derived table, these restrictions apply:
-
The
DUALtable can be used in aSELECTstatement that references no other tables, but needs to return at least one row. Selecting fromDUALis useful for computing a constant expression (an expression that is evaluated to a constant value) with theSELECTstatement. BecauseDUALhas only one row, the constant is returned only once. -
Subquerycannot refer to a column from another derived table. -
A derived table cannot be used as a source of a joined table.
-
A derived table cannot be used as a target of a
DELETEorUPDATEstatement.
GROUP BY clause
Specify the GROUP BY clause if you want the database to group the selected rows based on the value of expressions for each row and return a single row of summary information for each group. If the GROUP BY clause is omitted, the entire query result is treated as one group. If this clause contains CUBE or ROLLUP, the results contain superaggregate groupings in addition to the regular groupings.
The expressions in the GROUP BY clause can do the following:
-
Designate single or multiple columns.
-
Include arithmetic operations, the
ROWIDpseudocolumn, orNULL. -
Include a date, a constant, or a dynamic parameter.
-
Include
ROLLUPorCUBEclauses, where the results produce superaggregate groupings in addition to the regular groupings. Superaggregate groupings are calculated subtotals and totals returned with the regular groupings in theGROUP BYclause. -
Include
GROUPING SETSclause to distinguish which superaggregate groupings to produce.
When you use the GROUP BY clause, the select list can contain only aggregate functions and columns referenced in the GROUP BY clause. If the select list contains the construct *, TableName.*, or Owner.TableName.*, the GROUP BY clause must contain all columns that the * includes. NULL values are considered equivalent in grouping rows. If all other columns are equal, all NULL values in a column are placed in a single group.
Note:
To identify and potentially eliminate NULL groupings from the superaggregate groupings, use the GROUPING function. See "GROUPING" for information.
SQL syntax
The general syntax for the GROUP BY clause is the following:
GROUP BY
{Expression | RollupCubeClause | GroupingSetsClause }[,...]
GroupingSetsClause::= GROUPING SETS
GroupingExpressionList | RollupCubeClause [,...]
RollupCubeClause
{ ROLLUP | CUBE } ( GroupingExpressionList ) }
GroupingExpressionList::=
{ Expression | ExpressionList [, { Expression | ExpressionList } ] ...}
ExpressionList :: = ( Expression [, Expression ] ...)Parameters
| Parameter | Description |
|---|---|
|
|
Valid expression syntax. See Expressions for more information. |
|
|
The |
|
|
The |
|
|
The |
|
|
The |
|
|
The |
|
|
A list of one or more expressions, each separated by a comma. |
Examples
The following GROUP BY example sums the salaries for employees in the employees table and uses the SUBSTR expression to group the data by job function.
Command> SELECT SUBSTR (job_id, 4,10), SUM (salary) FROM employees
GROUP BY SUBSTR (job_id,4,10);
< PRES, 24000 >
< VP, 34000 >
< PROG, 28800 >
< MGR, 24000 >
< ACCOUNT, 47900 >
< MAN, 121400 >
< CLERK, 133900 >
< REP, 273000 >
< ASST, 4400 >
9 rows found.
Query emp_details_view to select the first 10 departments and managers within the department and count the number of employees in the department with the same manager. Use the GROUP BY clause to group the result by department and manager.
Command> columnlabels on; Command> SELECT first 10 department_id AS DEPT, manager_id AS MGR, COUNT(employee_id) AS NUM_EMP FROM emp_details_view GROUP BY (department_id, manager_id) ORDER BY department_id, manager_id; DEPT, MGR, NUM_EMP < 10, 101, 1 > < 20, 100, 1 > < 20, 201, 1 > < 30, 100, 1 > < 30, 114, 5 > < 40, 101, 1 > < 50, 100, 5 > < 50, 120, 8 > < 50, 121, 8 > < 50, 122, 8 > 10 rows found.
ROLLUP, CUBE and GROUPING SETS clauses
The following definitions describe how columns can be grouped within the ROLLUP, CUBE, and GROUPING SETS clauses:
-
Grouping column: A single column used in a
GROUP BYclause. For example, in the followingGROUP BYclause,X,Y, andZare group columns.GROUP BY X, GROUPING SETS(Y, Z)
-
Composite Column: A list of grouping columns inside parentheses. For example, in the following clause,
(C1, C2)and(C3, C4)are composite columns.GROUP BY ROLLUP( (C1,C2), (C3,C4), C5);
-
Grouping: Grouping is a single level of aggregation from within a grouping set. For example, in the following statement,
(C1)and(C2, C3)are individual groupings.GROUP BY GROUPING SETS(C1, (C2,C3));
-
Grouping Set: A collection of groupings inside parentheses. For example, in the following statement,
(C1, (C2, C3))and(C2, (C4, C5))are two individual grouping sets.GROUP BY GROUPING SETS(C1, (C2,C3)), GROUPING SETS(C2, (C4, C5));
-
Concatenated grouping sets: Separate multiple grouping sets with commas. The result is a cross-product of groupings from each grouping set.
-
Grand Total or Empty set column: A grand total or empty set grouping computes aggregation by considering all rows as one group. Grand totals are automatically provided in the results for
ROLLUPandCUBEclauses; however, you request the grand total in theGROUPING SETSclause by providing empty parentheses,( ).
Duplicate grouping columns can be used in ROLLUP, CUBE or GROUPING SETS. However, it does result in duplicated result rows.
The ROLLUP, CUBE and GROUPING SETS clauses are not supported in a materialized view definition.
The following sections describe the GROUPING SETS, ROLLUP, and CUBE clauses:
GROUPING SETS
The GROUPING SETS clause enables you to explicitly specify which groupings of data that the database returns. You specify only the desired groups by enclosing them within parentheses, so the database only generates the superaggregate summaries in which you are interested.
The following statement produces three groups: one group returns results for each gender and year columns, a second for a summary superaggregate for each of the months and the last result for the grand total.
SELECT GENDER, YEAR, MONTH,
SUM (NUM_OF_STUDENTS) AS TOTAL
FROM INSTRUCTOR_SUMMARY
GROUP BY GROUPING SETS ((GENDER, YEAR), -- 1ST GROUP
(MONTH), -- 2ND GROUP
()); -- 3RD GROUP
You can combine multiple GROUPING SETS to generate specific combinations between the multiple GROUPING SETS. The following statement contains two GROUPING SETS clauses:
GROUP BY GROUPING SETS (YEAR, MONTH),
GROUPING SETS (WEEK, DAY);
This is equivalent to the following GROUPING SETS statement:
GROUP BY GROUPING SETS (YEAR, WEEK), (YEAR, DAY), (MONTH, WEEK), (MONTH, DAY);
When a GROUP BY clause has both regular grouping columns and a GROUPING SETS clause, the results are grouped by the regular grouping column as follows:
GROUP BY a, b GROUPING SETS(c, d);
This is equivalent to the following:
GROUP BY GROUPING SETS((a, b, c), (a, b, d));
The following example specifies the grouping sets of (region_name, country_name), state_province, and grand totals.
Command> SELECT region_name AS Region,
country_name AS Country,
state_province AS State,
COUNT(employee_id) AS "Total Emp"
FROM regions r, countries c, locations l, departments d, employees e
WHERE r.region_id = c.region_id AND
l.country_id = c.country_id AND
d.location_id = l.location_id AND
d.department_id = e.department_id
GROUP BY grouping sets((region_name, country_name), state_province, ())
ORDER BY region_name, state_province;
REGION, COUNTRY, STATE, TOTAL EMP
< Americas, Canada, <NULL>, 2 >
< Americas, United States of America, <NULL>, 68 >
< Europe, Germany, <NULL>, 1 >
< Europe, United Kingdom, <NULL>, 35 >
< <NULL>, <NULL>, Bavaria, 1 >
< <NULL>, <NULL>, California, 45 >
< <NULL>, <NULL>, Ontario, 2 >
< <NULL>, <NULL>, Oxford, 34 >
< <NULL>, <NULL>, Texas, 5 >
< <NULL>, <NULL>, Washington, 18 >
< <NULL>, <NULL>, <NULL>, 106 >
< <NULL>, <NULL>, <NULL>, 1 >
12 rows found.ROLLUP
ROLLUP is used within the GROUP BY clause. When used with SUM, ROLLUP generates subtotals from most detailed level (all columns specified in the ROLLUP clause) to the grand total level, by removing one column at each level. These are known as superaggregate rows.
The ROLLUP clause returns the following:
-
Regular aggregate rows that would be produced by
GROUP BYwithout usingROLLUP. -
Subtotals following the grouping list specified in the
ROLLUPclause.ROLLUPtakes as its argument an ordered list of grouping columns. Each subtotal is created for the ordered list of grouping columns dropping the right-most grouping column until it reaches the grand total. For instance, if you specifyGROUP BY ROLLUP(x, y, z), the returned superaggregate groups would be as follows:(x,y,z), (x,y), (x), ( ).The number of subtotals created is
n+1aggregate levels, wherenis the number of grouping columns. For example, if there are three expressions (n=3) in theROLLUPclause, thenn+1 = 3+1, resulting in four groupings. -
Grand total row.
You can group columns using composite columns inside parentheses. For example, in the following statement:
GROUP BY ROLLUP( (a, b), (c, d), e);
The (a, b) and (c, d) composite columns are treated as a unit when the database produces the ROLLUP results. In this example, the grouping sets returned are as follows: ((a, b), (c, d), e ), ((a, b), (c, d)), (a, b) and ().
You can execute several ROLLUP clauses within your SELECT statement, as follows:
SELECT C1, COUNT(*) FROM T GROUP BY ROLLUP(a, b), ROLLUP(c, d);
This is equivalent to the following statement:
SELECT C1, COUNT(*) FROM T GROUP BY GROUPING SETS((a, b),(a),()), GROUPING SETS((c, d),(c), ());
This example queries the employees table to select the first 10 departments and return the number of employees under each manager in each department. Use ROLLUP to subtotal the number of employees in each department and return a grand total of all employees in the company.
Command> SELECT first 10 department_id AS Dept,
manager_id AS Mgr,
COUNT(employee_id) AS "Total emp"
FROM employees
GROUP BY ROLLUP(department_id, manager_id)
ORDER BY department_id, manager_id;
DEPT, MGR, TOTAL EMP
< 10, 101, 1 >
< 10, <NULL>, 1 >
< 20, 100, 1 >
< 20, 201, 1 >
< 20, <NULL>, 2 >
< 30, 100, 1 >
< 30, 114, 5 >
< 30, <NULL>, 6 >
< 40, 101, 1 >
< 40, <NULL>, 1 >
10 rows found.
The following query returns the number of employees in each region, country and state or province. The rollup returns superaggregate rows for subtotals of all employees in each state or province and in each country and a grand total for all employees in the company. By combining the region and country as its own unit (within parentheses), the rollup does not return all employees for each region.
Command> SELECT region_name AS Region,
country_name AS Country,
state_province AS State,
COUNT(employee_id) AS "Total Emp"
FROM regions r, countries c, locations l, departments d, employees e
WHERE r.region_id = c.region_id
AND l.country_id = c.country_id
AND d.location_id = l.location_id
AND d.department_id = e.department_id
GROUP BY rollup((region_name, country_name), state_province)
ORDER BY region_name;
REGION, COUNTRY, STATE, TOTAL EMP
< Americas, Canada, Ontario, 2 >
< Americas, United States of America, Texas, 5 >
< Americas, United States of America, California, 45 >
< Americas, United States of America, Washington, 18 >
< Americas, Canada, <NULL>, 2 >
< Americas, United States of America, <NULL>, 68 >
< Europe, Germany, Bavaria, 1 >
< Europe, United Kingdom, <NULL>, 1 >
< Europe, United Kingdom, Oxford, 34 >
< Europe, Germany, <NULL>, 1 >
< Europe, United Kingdom, <NULL>, 35 >
< <NULL>, <NULL>, <NULL>, 106 >
12 rows found. CUBE
The CUBE clause groups the selected rows based on the values of all possible combinations of the grouping columns in the CUBE clause. It returns a single row of summary information for each group. For example, if there are three expressions (n=3) in the CUBE clause, then 2n = 23, resulting in eight groupings. Rows grouped on the values of n expressions are called regular rows; all others are called superaggregate rows. You can group using composite columns. For example, a commonly requested CUBE operation is for state sales subtotals on all combinations of month, state, and product sold.
If you specify GROUP BY CUBE(a, b, c), the resulting aggregate groupings generated are as follows: (a,b,c), (a,b), (a,c), (b,c), a, b, c, ( ).
This example returns the number of employees for each region and country, issue the following query.
Command> SELECT region_name AS Region,
country_name AS Country,
COUNT(employee_id) AS "Total Emp"
FROM regions r, countries c, locations l, departments d, employees e
WHERE r.region_id = c.region_id
AND l.country_id = c.country_id
AND d.location_id = l.location_id
AND d.department_id = e.department_id
GROUP BY CUBE(region_name, country_name)
ORDER BY region_name;
REGION, COUNTRY, TOTAL EMP
< Americas, Canada, 2 >
< Americas, United States of America, 68 >
< Americas, <NULL>, 70 >
< Europe, Germany, 1 >
< Europe, United Kingdom, 35 >
< Europe, <NULL>, 36 >
< <NULL>, Canada, 2 >
< <NULL>, Germany, 1 >
< <NULL>, United Kingdom, 35 >
< <NULL>, United States of America, 68 >
< <NULL>, <NULL>, 106 >
11 rows found.TRUNCATE TABLE
The TRUNCATE TABLE statement is similar to a DELETE statement that deletes all rows.
In TimesTen Classic, the TRUNCATE operation is faster than the DELETE operation in most circumstances, as DELETE removes each row individually.
In TimesTen Scaleout, TRUNCATE TABLE is similar to a DDL statement that invalidates all commands that depend on the table being truncated. It is preferable to use the DELETE statement rather than the TRUNCATE statement to delete all rows in a table.
Required privilege
No privilege is required for the table owner.
DELETE for another user's table.
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
TRUNCATE TABLE [Owner.]TableName
Parameters
| Parameter | Description |
|---|---|
|
|
Identifies the table to be truncated. |
Description
-
TRUNCATEis a DDL statement. A commit is performed before and after execution of theTRUNCATEstatement. -
If your table has out of line columns and there are millions of rows to truncate, consider calling the
ttCompactbuilt-in procedure to free memory. -
Concurrent read committed read operations are allowed, and semantics of the reads are the same as for read committed reads in presence of
DELETEstatements. -
TRUNCATEis allowed even when there are child tables. However, child tables need to be empty forTRUNCATEto proceed. If any of the child tables have any rows in them, TimesTen returns an error indicating that a child table is not empty. -
TRUNCATEis not supported with any detail table of a materialized view, table that is a part of a cache group, or temporary table. -
When a table contains out of line varying-length data, the performance of
TRUNCATE TABLEis similar to that ofDELETEstatement that deletes all rows in a table. For more details on out-of line data, see "Numeric data types". -
Where tables are being replicated, the
TRUNCATEstatement replicates to the subscriber, even when no rows are operated upon. -
When tables are being replicated with timestamp conflict checking enabled, conflicts are not reported.
-
DROP TABLEandALTER TABLEoperations cannot be used to change hash pages on uncommitted truncated tables.
Examples
To delete all the rows from the recreation.clubs table, use:
TRUNCATE TABLE recreation.clubs;
See also
UNLOAD CACHE GROUP
The UNLOAD CACHE GROUP statement removes data from the cache group.
Required privilege
No privilege is required for the cache group owner.
UNLOAD or UNLOAD ANY CACHE GROUP for another user's cache group.
INSERT, DELETE, UPDATE privileges on underlying tables.
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
UNLOAD CACHE GROUP [Owner.]GroupName [WHERE ConditionalExpression] [COMMIT EVERY n ROWS]
or
UNLOAD CACHE GROUP [Owner.]GroupName WITH ID (ColumnValueList)
Note:
TheWITH ID clause is not supported in TimesTen Scaleout.
Parameters
| Parameter | Description |
|---|---|
|
|
Name assigned to the cache group. |
|
|
Use the |
|
|
Use the
If you specify this clause, the cache agent must be running and the unload must be the only operation in the transaction. Express To improve performance, use this clause when you are performing operations on cache groups that affect large amounts of data. Do not use this clause when you have cache groups with a small amount of data. |
|
|
The The |
Description
-
The
UNLOADCACHEGROUPstatement deletes rows from the TimesTen cache tables without affecting the data in the Oracle database tables. -
If your table has out of line columns and there are millions of rows, consider calling the
ttCompactbuilt-in procedure to free memory. -
If the cache group is replicated, an
UNLOAD CACHE GROUPstatement deletes the entire contents of any replicated cache group as well. -
Execution of the
UNLOAD CACHE GROUPstatement for an AWT cache group waits until updates on the rows have been propagated to the Oracle database. -
The
UNLOAD CACHE GROUPstatement can be used for any type of cache group. See "CREATE CACHE GROUP" for information on cache groups. -
Use the
UNLOAD CACHE GROUPstatement carefully with cache groups that have theAUTOREFRESHattribute. A row that is unloaded can reappear in the cache group as the result of an autorefresh operation if the row or its child rows are updated in the Oracle database. -
Following the execution of an
UNLOAD CACHE GROUPstatement, the ODBC functionSQLRowCount(), the JDBC methodgetUpdateCount(), and the OCI functionOCIAttrGet()with theOCI_ATTR_ROW_COUNTargument return the number of cache instances that were unloaded. -
If you specify the
COMMITEVERYnROWSclause, the cache agent performs the unload operation and commits the transaction after unloading the data. Make sure the cache agent is up and running. If you do not specify theCOMMITEVERYnROWSclause, the unload operation is executed by the application. -
If you specify the
COMMITEVERYnROWSclause, you cannot rollback the unload operation. If the unload operation fails when you specify theCOMMITEVERYnROWSclause (wheren>= 0), the cache group could be in an inconsistent state since some unloaded rows are already committed. Therefore, some cache instances may be partially unloaded. If this occurs, unload the cache group again. -
Use the
WITH IDclause to specify binding parameters. -
The
UNLOADCACHEGROUPoperation is executed in its own transaction.
Restrictions
-
The
UNLOADCACHEGROUP...WITHIDclause is not supported in TimesTen Scaleout. -
Do not reference child tables in the
WHEREclause. -
Do not user the
WITHIDclause on static read-only cache groups, or static user-managed cache groups with the autorefresh attribute. -
Do not use the
WITH IDclause with theCOMMIT EVERYnROWSclause.
Examples
Use the UNLOAD CACHE GROUP... COMMIT EVERY n ROWS to unload data from cached tables. The cache agent unloads the data because the COMMIT EVERY n ROWS clause is used.
Command> UNLOAD CACHE GROUP testcache WHERE sampleuser.orders.order_id > 100 COMMIT EVERY 100 ROWS; 2 cache instances affected.
CREATE and UNLOAD a cache group. The application performs the unload operation because the COMMIT EVERY n ROWS clause is not used.
CREATE CACHE GROUP recreation.cache FROM recreation.clubs ( clubname CHAR(15) NOT NULL, clubphone SMALLINT, activity CHAR(18), PRIMARY KEY(clubname)) WHERE (recreation.clubs.activity IS NOT NULL); UNLOAD CACHE GROUP recreation.cache;
UPDATE
The UPDATE statement updates the values of one or more columns in all rows of a table or in rows that satisfy a search condition.
Required privilege
No privilege is required for the table owner.
UPDATE for another user's table.
Usage with TimesTen Scaleout
This statement is supported with TimesTen Scaleout.
SQL syntax
UPDATE [hint] [FIRST NumRows] {[Owner.]TableName [CorrelationName]} SET {ColumnName = {Expression1 | NULL | DEFAULT}} [,...] [ WHERE SearchCondition ] RETURNING|RETURN Expression2[,...] INTO DataItem[,...]
Parameters
| Parameter | Description |
|---|---|
|
|
Specifies a statement level optimizer hint for the |
|
|
Specifies the number of rows to update. |
|
|
All correlation names within one statement must be unique. |
|
|
|
|
|
Any expression that does not contain an aggregate function. The expression is evaluated for each row qualifying for the update operation. The data type of the expression must be compatible with the data type of the updated column. |
|
|
Puts a |
|
|
Specifies that the column should be updated with the default value. |
|
|
The search condition can contain a subquery. All rows for which the search condition is true are updated as specified in the |
|
|
Valid expression syntax. See Expressions for information. |
|
|
Host variable or PL/SQL variable that stores the retrieved |
Description
-
For TimesTen Scaleout, you cannot update distribution key column(s) unless you update the column(s) to the same value.
-
You cannot update primary key column(s) unless you update the column(s) to the original value.
-
If the
WHEREclause is omitted, all rows of the table are updated as specified by theSETclause. -
TimesTen generates a warning when a character or binary string is truncated during an
UPDATEoperation. -
Constraint violations (
UNIQUE,FOREIGNKEY,NOTNULL) result in the failure of theUPDATEstatement. -
The
UPDATEoperation fails if it violates any foreign key constraint. See "CREATE TABLE" for a description of foreign key constraints. -
Restrictions on the
RETURNINGclause:-
Each
Expression2must be a simple expression. Aggregate functions are not supported. -
You cannot return a sequence number into an
OUTparameter. -
ROWNUMand subqueries cannot be used in theRETURNINGclause. -
Parameters in the
RETURNINGclause cannot be duplicated anywhere in theUPDATEstatement. -
Using the
RETURNINGclause to return multiple rows requires PL/SQLBULK COLLECTfunctionality. See "FORALL and BULK COLLECT operations" in Oracle TimesTen In-Memory Database PL/SQL Developer's Guide. -
In PL/SQL, you cannot use a
RETURNINGclause with aWHERE CURRENToperation.
-
Examples
Use the UPDATE statement to update employees with department_id = 110. For employees with department_id = 110, update the manager_id to the manager_id of employees with job_id = 'FI_ACCOUNT'. Use the DISTINCT qualifier in the subquery of the SET clause.
First find the manager_id of employees with job_id = 'FI_ACCOUNT.'
Command> SELECT manager_id FROM employees WHERE job_id = 'FI_ACCOUNT'; < 108 > < 108 > < 108 > < 108 > < 108 > 5 rows found.
Next find the manager_id of employees with department_id = 110.
Command> SELECT manager_id FROM employees WHERE department_id = 110; < 101 > < 205 > 2 rows found.
Now update the manager_id of employees with department_id = 110. Use SELECT DISTINCT in the subquery of the SET clause. After the UPDATE, verify the manager_id for employees with department_id = 110 was updated.
Command> UPDATE employees SET manager_id =
(SELECT DISTINCT employees.manager_id
FROM employees
WHERE employees.job_id = 'FI_ACCOUNT')
WHERE employees.department_id = 110;
2 rows updated.
Command> SELECT manager_id FROM employees WHERE department_id = 110;
< 108 >
< 108 >
2 rows found.
Use subqueries in the SET clause of the UPDATE statement. Update employees with location_id = 1700 or location_id = 2400. Set department_id for these employees to the department_id of location_id = 2500. (This is department_id 80). Set salary for these employees to the maximum salary of their department.
First query the first 5 employees to check their department_id and salary.
Command> SELECT FIRST 5 employee_id, department_id, salary
FROM employees
ORDER BY employee_id, department_id, salary;
< 100, 90, 24000 >
< 101, 90, 17000 >
< 102, 90, 17000 >
< 103, 60, 9000 >
< 104, 60, 6000 >
5 rows found.
Now use the UPDATE statement to update employees.
Command> UPDATE employees e1
SET department_id =
(SELECT department_id FROM departments
WHERE location_id = 2500),
salary =
(SELECT MAX(salary) FROM employees e2
WHERE e1.department_id = e2.department_id)
WHERE department_id IN
(SELECT department_id FROM departments
WHERE location_id = 2400 OR location_id = 1700);
19 rows updated.
Query the first five employees again to check that employees with the original department_id of 90 have been updated. The department_id is now 80 and the salary is 24000.
Command> SELECT FIRST 5 employee_id, department_id, salary
FROM employees
ORDER BY employee_id, department_id, salary;
< 100, 80, 24000 >
< 101, 80, 24000 >
< 102, 80, 24000 >
< 103, 60, 9000 >
< 104, 60, 6000 >
5 rows found.
The following example increases the price of parts costing more than $500 by 25 percent.
UPDATE purchasing.parts SET salesprice = salesprice * 1.25 WHERE salesprice > 500.00;
This next example updates the column with the NEXTVAL value from sequence seq.
UPDATE student SET studentno = seq.NEXTVAL WHERE name = 'Sally';
The following query updates the status of all the customers who have at least one unshipped order.
UPDATE customers SET customers.status = 'unshipped' WHERE customers.id = ANY (SELECT orders.custid FROM orders WHERE orders.status = 'unshipped');
The following statement updates all the duplicate orders, assuming id is not a primary key.
UPDATE orders a SET orders.status = 'shipped' WHERE EXISTS (SELECT 1 FROM orders b WHERE a.id = b.id AND a.rowid < b.rowid);
This next example updates job_id, salary and department_id for an employee whose last name is'Jones' in the employees table. The values of salary, last_name and department_id are returned into variables.
Command> VARIABLE bnd1 NUMBER(8,2);
Command> VARIABLE bnd2 VARCHAR2(25) INLINE NOT NULL;
Command> VARIABLE bnd3 NUMBER(4);
Command> UPDATE employees SET job_id='SA_MAN', salary=salary+1000,
department_id=140 WHERE last_name='Jones'
RETURNING salary*0.25, last_name, department_id
INTO :bnd1, :bnd2, :bnd3;
1 row updated.
Command> PRINT bnd1 bnd2 bnd3;
BND1 : 950
BND2 : Jones
BND3 : 140Join update
TimesTen supports join update statements. A join update can be used to update one or more columns of a table using the result of a subquery.
Syntax
UPDATE [Owner.]TableName SET ColumnName=Subquery [WHERE SearchCondition]
or
UPDATE [Owner.]TableName SET (ColumnName[,...])=Subquery [WHERE SearchCondition]
Parameters
A join update statement has the following parameters:
| Parameter | Description |
|---|---|
|
|
Identifies the table to be updated. |
|
|
Specifies the column to be updated. You can update several columns of the same table with a single The number of values in the select list of the subquery must be the same as the number of columns specified in the |
|
|
The search condition can contain a subquery. All rows for which the search condition is true are updated as specified in the |
Description
The subquery in the SET clause of a join update does not reduce the number of rows from the target table that are to be updated. The reduction must be specified using the WHERE clause. Thus if a row from the target table qualifies the WHERE clause but the subquery returns no rows for this row, this row is updated with a NULL value in the updated column.
Examples
In this example, if a row from t1 has no match in t2, then its x1 value in the first SELECT and its x1 and y1 values in the second SELECT are set to NULL.
UPDATE t1 SET x1=(SELECT x2 FROM t2 WHERE id1=id2); UPDATE t1 SET (x1,y1)=(SELECT x2,y2 FROM t2 WHERE id1=id2);
In order to restrict the UPDATE statement to update only rows from t1 that have a match in t2, a WHERE clause with a subquery has to be provided as follows.
UPDATE t1 SET x1=(SELECT x2 FROM t2 WHERE id1=id2) WHERE id1 IN (SELECT id2 FROM t2); UPDATE t1 SET (x1,y1)=(SELECT x2,y2 FROM t2 WHERE id1=id2) WHERE id1 IN (SELECT id2 FROM t2);
See also