The TimesTen ttIsql utility is a general tool for working with a TimesTen data source. The ttIsql command line interface is used to execute SQL statements and built-in ttIsql commands to perform various operations. Some common tasks that are typically accomplished using ttIsql include:
Database setup and maintenance. Creating tables and indexes, altering existing tables and updating table statistics can be performed quickly and easily using ttIsql.
Retrieval of information on database structures. The definitions for tables, indexes and cache groups can be retrieved using built-in ttIsql commands. In addition, the current size and state of the database can be displayed.
Optimizing database operations. The ttIsql utility can be used to alter and display query optimizer plans for the purpose of tuning SQL operations. The time required to execute various ODBC function calls can also be displayed.
The following sections describe how the ttIsql utility is used to perform these types of tasks:
For more information on ttIsql commands, see the "ttIsql" section in the Oracle TimesTen In-Memory Database Reference.
The ttIsql utility can be used in two distinctly different ways: batch mode or interactive mode. When ttIsql is used in interactive mode, users type commands directly into ttIsql from the console. When ttIsql is used in batch mode, a prepared script of ttIsql commands is executed by specifying the name of the file containing the commands.
Batch mode is commonly used for the following types of tasks:
Performing periodic maintenance operations including the updating of table statistics, compacting the database and purging log files.
Initializing a database by creating tables, indexes and cache groups and then populating the tables with data.
Generating simple reports by executing common queries.
Interactive mode is suited for the following types of tasks:
Experimenting with TimesTen features, testing design alternatives and improving query performance.
Solving database problems by examining database statistics.
Any other database tasks that are not performed routinely.
By default, when starting ttIsql from the shell, ttIsql is in interactive mode. The ttIsql utility prompts you to type in a valid ttIsql built-in command or SQL statement by printing the Command> prompt. The following example starts ttIsql in interactive mode and then connects to a TimesTen database by executing the connect command with the MY_DSN DSN.
C:\>ttIsql Copyright (c) 1996-2011, Oracle. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. Command> connect MY_DSN; Connection successful: DSN=MY_DSN;DataStore=E:\ds\MY_DSN; DRIVER=E:\WINNT\System32\TTdv1122.dll; (Default setting AutoCommit=1) Command>
When connecting to the database using ttIsql, you can also specify the DSN or connection string on the ttIsql command line. The connect command is implicitly executed.
C:\>ttIsql MY_DSN Copyright (c) 1996-2011, Oracle. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=MY_DSN"; Connection successful: DSN=MY_DSN;DataStore=E:\ds\MY_DSN; DRIVER=E:\WINNT\System32\TTdv1122.dll; (Default setting AutoCommit=1) Command>
Batch mode can be accessed in two different ways. The most common way is to specify the -f option on the ttIsql command line followed by the name of file to run.
For example, executing a file containing a CREATE TABLE statement will look like this:
C:\>ttIsql -f create.sql MY_DSN Copyright (c) 1996-2011, Oracle. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. Command> connect "DSN=MY_DSN" Connection successful: DSN=MY_DSN;DataStore=E:\ds\MY_DSN; DRIVER=E:\WINNT\System32\TTdv1122.dll; (Default setting AutoCommit=1) Command> run "create.sql" CREATE TABLE LOOKUP (KEY NUMBER NOT NULL PRIMARY KEY, VALUE CHAR (64)) Command> exit Disconnecting... Done. C:\>
The other way to use batch mode is to enter the run command directly from the interactive command prompt. The run command is followed by the name of the file containing ttIsql built-in commands and SQL statements to execute:
Command> run "create.sql"; CREATE TABLE LOOKUP (KEY NUMBER NOT NULL PRIMARY KEY, VALUE CHAR (64)) Command>
The ttIsql utility can be customized to automatically execute a set of command line options every time a ttIsql session is started from the command prompt. This is accomplished by setting an environment variable called TTISQL to the value of the ttIsql command line that you prefer. A summary of ttIsql command line options is shown below. For a complete description of the ttIsql command line options, see the "ttIsql" section in the Oracle TimesTen In-Memory Database Reference.
Usage: ttIsql [-h | -help | -helpcmds | -helpfull | -V]
ttIsql [-f <filename>]
[-v <verbosity>]
[-e <commands>]
[-interactive]
[-N <ncharEncoding>]
[-wait]
[{<DSN> | -connstr <connection_string>}]
The TTISQL environment variable has the same syntax requirements as the ttIsql command line. When ttIsql starts up it reads the value of the TTISQL environment variable and applies all options specified by the variable to the current ttIsql session. If a particular command line option is specified in both the TTISQL environment variable and the command line then the command line version will always take precedence.
The procedure for setting the value of an environment variable differs based on the platform and shell that ttIsql is started from. As an example, setting the TTISQL environment variable on Windows could look like this:
C:\>set TTISQL=-connStr "DSN=MY_DSN" -e "autocommit 0;dssize;"
In this example, ttIsql will automatically connect to a DSN called MY_DSN, turn off autocommit and display the size of the database as shown below:
C:\>ttIsql Copyright (c) 1996-2011, Oracle. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. Command> connect "DSN=MY_DSN"; Connection successful: DSN=MY_DSN;DataStore=E:\ds\MY_DSN; DRIVER=E:\WINNT\System32\TTdv1122.dll; (Default setting AutoCommit=1) Command> autocommit 0; Command> alltables; SYS.ACCESS$ SYS.ARGUMENT$ SYS.CACHE_GROUP SYS.COLUMNS SYS.COLUMN_HISTORY SYS.COL_STATS SYS.DEPENDENCY$ SYS.DIR$ SYS.DUAL SYS.ERROR$ SYS.IDL_CHAR$ SYS.IDL_SB4$ SYS.IDL_UB1$ SYS.IDL_UB2$ SYS.INDEXES SYS.MONITOR ... 59 tables found. Command>
You can customize the ttIsql command prompt by using the set command with the prompt attribute:
Command> set prompt MY_DSN; MY_DSN
You can specify a string format (%c) that returns the name of the current connection:
Command> set prompt %c; con1
If you want to embed spaces, you must quote the string:
Command> set prompt "MY_DSN %c> "; MY_DSN con1>
The ttIsql utility has an online version of command syntax definitions and descriptions for all built-in ttIsql commands. To access this online help from within ttIsql use the help command. To view a detailed description of any built-in ttIsql commands type the help command followed by one or more ttIsql commands to display help for. The example below displays the online description for the connect and disconnect commands.
Command> help connect disconnect Arguments in <> are required. Arguments in [] are optional. Command Usage: connect [DSN|connection_string] [as <connection_id>] Command Aliases: (none) Description: Connects to the data source specified by the optional DSN or connection string argument. If an argument is not given, then the DSN or connection string from the last successful connection is used. A connection ID may optionally be specified, for use in referring to the connection when multiple connections are enabled. The DSN is used as the default connection ID. If that ID is already in use, the connection will be assigned the ID "conN", where N is some number larger than 0. Requires an active connection: NO Requires autocommit turned off: NO Reports elapsed execution time: YES Works only with a TimesTen data source: NO Example: connect; -or- connect RunData; -or- connect "DSN=RunData"; -or- connect RunData as rundata1; Command Usage: disconnect [all] Command Aliases: (none) Description: Disconnects from the currently connected data source or all connections when the "all" argument is included. If a transaction is active when disconnecting then the transaction will be rolled back automatically. If a connection exists when executing the "bye", "quit" or "exit" commands then the "disconnect" command will be executed automatically. Requires an active connection: NO Requires autocommit turned off: NO Reports elapsed execution time: YES Works only with a TimesTen data source: NO Example: disconnect;
To view a short description of all ttIsql built-in commands type the help command without an argument. To view a detailed description of all built-in ttIsql commands type the help command followed by the all argument.
To view the list of attributes that can be set or shown by using ttIsql, enter:
Command> help attributes
On UNIX systems, you can use the 'editline' library to set up emacs (default) or vi bindings that enable you to scroll through previous ttIsql commands, as well as edit and resubmit them. This feature is not available or needed on Windows.
To disable the 'editline' feature in ttIsql, use the ttIsql command set editline off.
The set up and keystroke information is described for each type of editor:
To use the emacs binding, create a file ~/.editrc and put "bind" on the last line of the file, run ttIsql. The editline lib will print the current bindings.
The keystrokes when using ttIsql with the emacs binding are:
| Keystroke | Action |
|---|---|
| <Left-Arrow> | Move the insertion point left. Back up. |
| <Right-Arrow> | Move the insertion point right. Move forward. |
| <Up-Arrow> | Scroll to the command prior to the one being displayed. Places the cursor at the end of the line. |
| <Down-Arrow> | Scroll to a more recent command history item and put the cursor at the end of the line. |
| <Ctrl-A> | Move the insertion point to the beginning of the line. |
| <Ctrl-E> | Move the insertion point to the end of the line. |
| <Ctrl-K> | "Kill" (Save and erase) the characters on the command line from the current position to the end of the line. |
| <Ctrl-Y> | "Yank" (Restore) the characters previously saved and insert them at the current insertion point. |
| <Ctrl-F> | Forward char - move forward 1 (see Right Arrow) |
| <Ctrl-B> | Backward char - move back 1 (see Left Arrow) |
| <Ctrl-P> | Previous History (see Up Arrow) |
| <Ctrl-N> | Next History (see up Down Arrow) |
To use the vi bindings, create a file ${HOME}/.editrc and put "bind-v" in the file, run ttIsql. To get the current settings, create a file ${HOME}/.editrc and put "bind" on the last line of the file. When you execute ttIsql, the editline lib will print the current bindings.
The keystrokes when using ttIsql with the vi binding are:
| Keystroke | Action |
|---|---|
| <Left-Arrow>, h | Move the insertion point left (back up) |
| <Right-Arrow>, l | Move the insertion point right (forward) |
| <Up-Arrow>, k | Scroll to the prior command in the history and put the cursor at the end of the line. |
| <Down-Arrow>, j | Scroll to the next command in the history and put the cursor at the end of the line. |
| ESC | Vi Command mode |
| 0, $ | Move the insertion point to the beginning of the line, Move to end of the line. |
| i, I | Insert mode, Insert mode at beginning of the line |
| a, A | Add ("Insert after") mode, Append at end of line |
| R | Replace mode |
| C | Change to end of line |
| B | Move to previous word |
| e | Move to end of word |
| <Ctrl-P> | Previous History (see Up Arrow) |
| <Ctrl-N> | Next History (see up Down Arrow) |
The ttIsql utility stores a list of the last 100 commands executed within the current ttIsql session. The commands in this list can be viewed or executed again without having to type the entire command over. Both SQL statements and built-in ttIsql commands are stored in the history list. Use the history command ("h ") to view the list of previously executed commands. For example:
Command> h; 8 INSERT INTO T3 VALUES (3) 9 INSERT INTO T1 VALUES (4) 10 INSERT INTO T2 VALUES (5) 11 INSERT INTO T3 VALUES (6) 12 autocommit 0 13 showplan 14 SELECT * FROM T1, t2, t3 WHERE A=B AND B=C AND A=B 15 trytbllocks 0 16 tryserial 0 17 SELECT * FROM T1, t2, t3 WHERE A=B AND B=C AND A=B Command>
The history command displays the last 10 SQL statements or ttIsql built-in commands executed. To display more than that last 10 commands specify the maximum number to display as an argument to the history command.
Each entry in the history list is identified by a unique number. The ! character followed by the number of the command can be used to execute the command again. For example:
Command> Command> ! 12; autocommit 0 Command>
To execute the last command again simply type a sequence of two ! characters:
Command> !!; autocommit 0 Command>
To execute the last command that begins with a given string type the ! character followed by the first few letters of the command. For example:
Command> ! auto; autocommit 0 Command>
You can save the list of commands that ttIsql stores by using the savehistory command:
Command> savehistory history.txt;
If the output file already exists, use the -a option to append the new command history to the file or the -f option to overwrite the file. The next example shows how to append new command history to an existing file.
Command> savehistory -a history.txt;
You can clear the list of commands that ttIsql stores by using the clearhistory command:
Command> clearhistory;
The ttIsql utility supports the character sets listed in "Supported character sets" in the Oracle TimesTen In-Memory Database Reference. The ability of ttIsql to display characters depends on the native operating system locale settings of the terminal on which you are using ttIsql.
To override the locale-based output format, use the ncharencoding option or the -N option. The valid values for these options are LOCALE (the default) and ASCII. If you choose ASCII and ttIsql encounters a Unicode character, it displays it in escaped format.
You do not need to have an active connection to change the output method.
There are several ttIsql commands that display information on database structures. The most useful commands are summarized below:
dssize - Reports the current sizes of the permanent and temporary database partitions.
tablesize - Displays the size of tables that have been analyzed with the ttComputeTabSizes tool.
monitor - Displays a summary of the current state of the database.
Use the describe command to display information on individual database objects. Displays parameters for prepared SQL statements and built-in procedures. The argument to the describe command can be the name of a table, cache group, view, materialized view, materialized view log, sequence, synonym, a built-in procedure, a SQL statement or a command ID for a previously prepared SQL statement, a PL/SQL function, PL/SQL procedure or PL/SQL package.
The describe command requires a semicolon character to terminate the command.
Command> CREATE TABLE T1 (KEY NUMBER NOT NULL PRIMARY KEY, VALUE CHAR (64));
Command> describe T1
> ;
Table USER.T1:
Columns:
*KEY NUMBER NOT NULL
VALUE CHAR (64)
1 table found.
(primary key columns are indicated with *)
Command> describe SELECT * FROM T1 WHERE KEY=?;
Prepared Statement:
Parameters:
Parameter 1 NUMBER
Columns:
KEY NUMBER NOT NULL
VALUE CHAR (64)
Command> describe ttOptUseIndex;
Procedure TTOPTUSEINDEX:
Parameters:
Parameter INDOPTION VARCHAR (1024)
Columns:
(none)
1 procedure found.
Command>
The cachegroups command is used to provide detailed information on cache groups defined in the current database. The attributes of the root and child tables defined in the cache group are displayed in addition to the WHERE clauses associated with the cache group. The argument to the cachegroups command is the name of the cache group that you want to display information for.
Command> cachegroups; Cache Group CACHEUSER.READCACHE: Cache Group Type: Read Only Autorefresh: Yes Autorefresh Mode: Incremental Autorefresh State: Paused Autorefresh Interval: 5 Seconds Autorefresh Status: ok Aging: No aging defined Root Table: ORATT.READTAB Table Type: Read Only Cache Group CACHEUSER.WRITECACHE: Cache Group Type: Asynchronous Writethrough global (Dynamic) Autorefresh: No Aging: LRU on Root Table: ORATT.WRITETAB Table Type: Propagate 2 cache groups found.
The dssize command is used to report the current memory status of the permanent and temporary partitions as well as the maximum, allocated and in-use sizes for the database.
Command> dssize PERM_ALLOCATED_SIZE: 32768 PERM_IN_USE_SIZE: 8615 PERM_IN_USE_HIGH_WATER: 8615 TEMP_ALLOCATED_SIZE: 40960 TEMP_IN_USE_SIZE: 5794 TEMP_IN_USE_HIGH_WATER: 8959
The tablesize command displays the detailed analysis of the amount of space used by a table. Once you execute the ttComputeTabSizes built-in procedure, which analyzes the table size of the indicated tables, the tablesize command displays the total size data for all analyzed tables.
Executing the tablesize command with no arguments displays available sizing information for all tables that have had the ttComputeTabSizes computation run. When you provide a table as an argument, tablesize displays available sizing only for the indicated table.
The syntax for tablesize is as follows:
tablesize [[owner_name_pattern.]table_name_pattern]
The following example invokes the ttComputeTabSizes built-in procedure to calculate the table size of the employees table. Then, the tablesize command displays the sizing information gathered for the employees table.
Command> call ttComputeTabSizes('employees');
Command> tablesize employees;
Sizes of USER1.EMPLOYEES:
INLINE_ALLOC_BYTES: 60432
NUM_USED_ROWS: 107
NUM_FREE_ROWS: 149
AVG_ROW_LEN: 236
OUT_OF_LINE_BYTES: 0
METADATA_BYTES: 1304
TOTAL_BYTES: 61736
LAST_UPDATED: 2011-06-29 12:55:28.000000
1 table found.
These values provide insights into overhead and how the total space is used for the table.
For example:
The NUM_FREE_ROWS value describes the number of rows allocated for the table, but not currently in use. Space occupied by free rows cannot be used by the system for storing other system objects or structures.
Use the TOTAL_BYTES value to calculate how much permanent space your table occupies.
LAST_UPDATED is the time of the last size computation. If you want a more recent computation, re-execute ttComputeTabSizes and display the new output.
You can find a description for each calculated value in the "SYS.ALL_TAB_SIZES" section in the Oracle TimesTen In-Memory Database System Tables and Views Reference.
The monitor command displays all of the information provided by the dssize command plus additional statistics on the number of connections, checkpoints, lock timeouts, commits, rollbacks and other information collected since the last time the database was loaded into memory.
Command> monitor; TIME_OF_1ST_CONNECT: Wed Apr 20 10:34:17 2011 DS_CONNECTS: 11 DS_DISCONNECTS: 0 DS_CHECKPOINTS: 0 DS_CHECKPOINTS_FUZZY: 0 DS_COMPACTS: 0 PERM_ALLOCATED_SIZE: 40960 PERM_IN_USE_SIZE: 5174 PERM_IN_USE_HIGH_WATER: 5174 TEMP_ALLOCATED_SIZE: 18432 TEMP_IN_USE_SIZE: 4527 TEMP_IN_USE_HIGH_WATER: 4527 SYS18: 0 TPL_FETCHES: 0 TPL_EXECS: 0 CACHE_HITS: 0 PASSTHROUGH_COUNT: 0 XACT_BEGINS: 2 XACT_COMMITS: 1 XACT_D_COMMITS: 0 XACT_ROLLBACKS: 0 LOG_FORCES: 0 DEADLOCKS: 0 LOCK_TIMEOUTS: 0 LOCK_GRANTS_IMMED: 17 LOCK_GRANTS_WAIT: 0 SYS19: 0 CMD_PREPARES: 1 CMD_REPREPARES: 0 CMD_TEMP_INDEXES: 0 LAST_LOG_FILE: 0 REPHOLD_LOG_FILE: -1 REPHOLD_LOG_OFF: -1 REP_XACT_COUNT: 0 REP_CONFLICT_COUNT: 0 REP_PEER_CONNECTIONS: 0 REP_PEER_RETRIES: 0 FIRST_LOG_FILE: 0 LOG_BYTES_TO_LOG_BUFFER: 64 LOG_FS_READS: 0 LOG_FS_WRITES: 0 LOG_BUFFER_WAITS: 0 CHECKPOINT_BYTES_WRITTEN: 0 CURSOR_OPENS: 1 CURSOR_CLOSES: 1 SYS3: 0 SYS4: 0 SYS5: 0 SYS6: 0 CHECKPOINT_BLOCKS_WRITTEN: 0 CHECKPOINT_WRITES: 0 REQUIRED_RECOVERY: 0 SYS11: 0 SYS12: 1 TYPE_MODE: 0 SYS13: 0 SYS14: 0 SYS15: 0 SYS16: 0 SYS17: 0 SYS9:
You can use ttIsql to list tables, indexes, views, sequences, synonyms, PL/SQL functions, procedures and packages in a database. Commands prefixed by all display all of this type of object. For example, the functions command lists PL/SQL functions that are owned by the user, whereas allfunctions lists all PL/SQL functions.
You can optionally specify patterns for object owners and object names.
Use these commands to list database objects:
tables and alltables - Lists tables
indexes and allindexes - Lists indexes
views and allviews - Lists views
sequences and allsequences - Lists sequences
synonyms and allsynonyms - Lists synonyms
functions and allfunctions - Lists PL/SQL functions
procedures and allprocedures - Lists PL/SQL procedures
packages and allpackages - Lists PL/SQL packages
|
Note: For details on each of these commands, see the "ttIsql" section in the Oracle TimesTen In-Memory Database Reference. |
The following example demonstrates the procedures and allprocedures commands. User TERRY creates a procedure called proc1 while connected to myDSN. Note that a slash character (/) is entered on a new line following the PL/SQL statements.
The procedures command and the allprocedures command show that it is the only PL/SQL procedure in the database.
$ ttisql myDSN
Copyright (c) 1996-2011, Oracle. All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.
connect "DSN=myDSN";
Connection successful:
DSN=myDSN;UID=terry;DataStore=/scratch/terry/myDSN;DatabaseCharacter
Set=AL32UTF8;ConnectionCharacterSet=US7ASCII;PermSize=32;TypeMode=0;
(Default setting AutoCommit=1)
Command> create or replace procedure proc1 as begin null; end;
> /
Procedure created.
Command> procedures;
TERRY.PROC1
1 procedure found.
Command> allprocedures;
TERRY.PROC1
1 procedure found.
Now connect to the same DSN as Pat and create a procedure called q. The allprocedures command shows the PL/SQL procedures created by Terry and pat.
$ ttisql "dsn=myDSN;uid=PAT"
Copyright (c) 1996-2011, Oracle. All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.
connect "dsn=myDSN;uid=PAT";
Connection successful: DSN=myDSN;UID=PAT;
DataStore=/scratch/terry/myDSN;DatabaseCharacterSet=AL32UTF8;
ConnectionCharacterSet=US7ASCII;PermSize=32;TypeMode=0;
(Default setting AutoCommit=1)
Command> create or replace procedure q as begin null; end;
> /
Procedure created.
Command> procedures;
PAT.Q
1 procedure found.
Command> allprocedures;
TERRY.PROC1
PAT.Q
2 procedures found.
You can view and set connection attributes with the ttIsql show and set commands. For a list of the attributes that you can view and set with ttIsql, see "Connection Attributes" in Oracle TimesTen In-Memory Database Reference.
To view the setting for the Passthrough attribute, enter:
Command> show passthrough; PassThrough = 0
To change the Passthrough setting, enter:
Command> set passthrough 1;
The ttIsql utility has several built-in commands for managing transactions. These commands are summarized below:
autocommit - Turns on or off the autocommit feature. This can also be set as an attribute of the set command.
commitdurable - Commits the current transaction and ensures that the committed work will be recovered in case of database failure.
isolation - Changes the transaction isolation level. This can also be set as an attribute of the set command.
sqlquerytimeout - Specifies the number of seconds to wait for a SQL statement to execute before returning to the application. This can also be set as an attribute of the set command.
When starting ttIsql, the autocommit feature is turned on by default, even within a SQL script. In this mode, every SQL operation against the database is committed automatically. When autocommit is turned off, then automatic commit depends on the setting for the DDLCommitBehavior connection attribute and the user executing DDL. For more information, see "Relationship between autocommit and DDLCommitBehavior".
To turn the autocommit feature off, execute the ttIsql autocommit command with an argument of 0. When autocommit is turned off, transactions must be committed or rolled back manually by executing the ttIsql commit, commitdurable or rollback commands. The commitdurable command ensures that the transaction's effect is preserved in case of database failure. If autocommit is off when ttIsql exits, any uncommitted statements will be rolled back and reported by ttIsql.
The ttIsql isolation command can be used to change the current connection's transaction isolation properties. The isolation can be changed only at the beginning of a transaction. The isolation command accepts one of the following constants: READ_COMMITTED and SERIALIZABLE. If the isolation command is modified without an argument then the current isolation level is reported.
The ttIsql sqlquerytimeout command sets the timeout period for SQL statements. If the execution time of a SQL statement exceeds the number of seconds set by the sqlquerytimeout command, the SQL statement is not executed and an 6111 error is generated. For details, see "Setting a timeout duration for SQL statements" in the Oracle TimesTen In-Memory Database Java Developer's Guide and "Setting a timeout duration for SQL statements" in the Oracle TimesTen In-Memory Database C Developer's Guide.
|
Note: TimesTen rollback and query timeout features do not stop IMDB Cache operations that are being processed on Oracle. This includes passthrough statements, flushing, manual loading, manual refreshing, synchronous writethrough, propagating and dynamic loading. |
The following example demonstrates the common use of the ttIsql built-in transaction management commands.
E:\>ttIsql Copyright (c) 1996-2011, Oracle. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. Command> connect "DSN=MY_DSN"; Connection successful: DSN=MY_DSN;DataStore=E:\ds\MY_DSN; DRIVER=E:\WINNT\System32\TTdv1122.dll; (Default setting AutoCommit=1) Command> autocommit 0; Command> CREATE TABLE LOOKUP (KEY NUMBER NOT NULL PRIMARY KEY, VALUE CHAR (64)); Command> commit; Command> INSERT INTO LOOKUP VALUES (1, 'ABC'); 1 row inserted. Command> SELECT * FROM LOOKUP; < 1, ABC > 1 row found. Command> rollback; Command> SELECT * FROM LOOKUP; 0 rows found. Command> isolation; isolation = READ_COMMITTED Command> commitdurable; Command> sqlquerytimeout 10; Command> sqlquerytimeout; Query timeout = 10 seconds Command> disconnect; Disconnecting... Command> exit; Done.
Preparing a SQL statement just once and then executing it multiple times is much more efficient for TimesTen applications than re-preparing the statement each time it is to be executed. ttIsql has a set of built-in commands to work with prepared SQL statements. These commands are summarized below:
prepare - Prepares a SQL statement. Corresponds to a SQLPrepare ODBC call.
exec - Executes a previously prepared statement. Corresponds to a SQLExecute ODBC call.
execandfetch - Executes a previously prepared statement and fetches all result rows. Corresponds to a SQLExecute call followed by one or more calls to SQLFetch.
fetchall - Fetches all result rows for a previously executed statement. Corresponds to one or more SQLFetch calls.
fetchone - Fetches only one row for a previously executed statement. Corresponds to exactly one SQLFetch call.
close - Closes the result set cursor on a previously executed statement that generated a result set. Corresponds to a SQLFreeStmt call with the SQL_CLOSE option.
free - Closes a previously prepared statement. Corresponds to a SQLFreeStmt call with the SQL_DROP option.
describe - Describes the prepared statement including the input parameters and the result columns.
The ttIsql utility prepared statement commands also handle SQL statement parameter markers. When parameter markers are included in a prepared SQL statement, ttIsql will automatically prompt for the value of each parameter in the statement at execution time.
The example below uses the prepared statement commands of the ttIsql utility to prepare an INSERT statement into a table containing a NUMBER and a CHAR column. The statement is prepared and then executed twice with different values for each of the statement's two parameters. The ttIsql utility timing command is used to display the elapsed time required to executed the primary ODBC function call associated with each command.
Command> connect "DSN=MY_DSN"; Connection successful: DSN=MY_DSN;DataStore=E:\ds\MY_DSN;DRIVER= E:\WINNT\System32\TTdv1122.dll; (Default setting AutoCommit=1) Command> timing 1; Command> create table t1 (key number not null primary key, value char(20)); Execution time (SQLExecute) = 0.007247 seconds. Command> prepare insert into t1 values (:f, :g); Execution time (SQLPrepare) = 0.000603 seconds. Command> exec; 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 'F' (NUMBER) > 1; Enter Parameter 2 'G' (CHAR) > 'abc'; 1 row inserted. Execution time (SQLExecute) = 0.000454 seconds. Command> exec; 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 help command. Enter Parameter 1 'F' (NUMBER) > 2; Enter Parameter 2 'G' (CHAR) > 'def'; 1 row inserted. Execution time (SQLExecute) = 0.000300 seconds. Command> free; Command> select * from t1; < 1, abc > < 2, def > 2 rows found. Execution time (SQLExecute + Fetch Loop) = 0.000226 seconds. Command> disconnect; Disconnecting... Execution time (SQLDisconnect) = 2.911396 seconds. Command>
In the example above, the prepare command is immediately followed by the SQL statement to prepare. Whenever a SQL statement is prepared in ttIsql, a unique command ID is assigned to the prepared statement. The ttIsql utility uses this ID to keep track of multiple prepared statements. A maximum of 256 prepared statements can exist in a ttIsql session simultaneously. When the free command is executed, the command ID is automatically disassociated from the prepared SQL statement.
To see the command IDs generated by ttIsql when using the prepared statement commands, set the verbosity level to 4 using the verbosity command before preparing the statement, or use the describe * command to list all prepared statements with their IDs.
Command IDs can be referenced explicitly when using ttIsql's prepared statement commands. For a complete description of the syntax of ttIsql's prepared statement commands see the "ttIsql" section in the Oracle TimesTen In-Memory Database Reference or type help at the ttIsql command prompt.
The example below prepares and executes a SELECT statement with a predicate containing one NUMBER parameter. The fetchone command is used to fetch the result row generated by the statement. The showplan command is used to display the execution plan used by the TimesTen query optimizer when the statement is executed. In addition, the verbosity level is set to 4 so that the command ID used by ttIsql to keep track of the prepared statement is displayed.
Command> connect "DSN=MY_DSN"; Connection successful: DSN=MY_DSN;DataStore=E:\ds\MY_DSN; DRIVER=E:\WINNT\Sys tem32\TTdv1122.dll; (Default setting AutoCommit=1) The command succeeded. Command> CREATE TABLE T1 (KEY NUMBER NOT NULL PRIMARY KEY, VALUE CHAR (64)); The command succeeded. Command> INSERT INTO T1 VALUES (1, 'abc'); 1 row inserted. The command succeeded. Command> autocommit 0; The command succeeded. Command> showplan 1; The command succeeded. Command> verbosity 4; The command succeeded. Command> prepare SELECT * FROM T1 WHERE KEY=?; Assigning new prepared command id = 0. Query Optimizer Plan: STEP: 1 LEVEL: 1 OPERATION: RowLkHashScan TBLNAME: T1 IXNAME: T1 PRED: T1.KEY = qmark_1 OTHERPRED: <NULL> The command succeeded. Command> exec; Executing prepared command id = 0. Type '?;' for help on entering parameter values. Type '*;' to abort the parameter entry process. Enter Parameter 1 (NUMBER) >1; The command succeeded. Command> fetchone; Fetching prepared command id = 0. < 1, abc > 1 row found. The command succeeded. Command> close; Closing prepared command id = 0. The command succeeded. Command> free; Freeing prepared command id = 0. The command succeeded. Command> commit; The command succeeded. Command> disconnect; Disconnecting... The command succeeded. Command>
|
Note: For information about usingttIsql with PL/SQL host variables, see "Introduction to PL/SQL in the TimesTen Database" in Oracle TimesTen In-Memory Database PL/SQL Developer's Guide. |
The following sections describe how to declare, set and use bind variables in ttIsql:
You can declare and set variables and arrays in ttIsql that can be referenced in a SQL statement, SQL script, or PL/SQL block. The variables declared using the variable and setvariable command must be one of the following data types: NUMBER, CHAR, NCHAR, VARCHAR2, NVARCHAR2, CLOB, NCLOB, BLOB, or REFCURSOR. However, when binding arrays, Timesten supports only binding arrays of the NUMBER, CHAR, NCHAR, VARCHAR2, or NVARCHAR2 data types.
|
Note: All variables that are declared exist for the life of the ttIsql session. However, if you declare a new variable with the same name, the new variable replaces the old variable. |
The following examples declare bind variables with the variable or var command for a number, character string, and an array. Each is assigned to a value either when declared or by using the setvariable or setvar command.
|
Note: For details on the syntax for these commands, see "ttIsql" in the Oracle TimesTen In-Memory Database Reference. |
Command> VARIABLE house_number NUMBER := 268; Command> PRINT house_number; HOUSE_NUMBER : 268 Command> VARIABLE street_name VARCHAR2(15); Command> SETVARIABLE street_name := 'Oracle Parkway'; Command> VARIABLE occupants[5] VARCHAR2(15); Command> SETVARIABLE occupants[1] := 'Pat'; Command> SETVARIABLE occupants[2] := 'Terry'; Command> PRINT occupants; OCCUPANTS : ARRAY [ 5 ] (Current Size 2) OCCUPANTS[1] : Pat OCCUPANTS[2] : Terry
The following is an example of binding multiple values in an array using square brackets to delineate the values and commas to separate each value for the array:
Command> VARIABLE occupants[5] VARCHAR2(15) := ['Pat', 'Terry']; Command> PRINT occupants; OCCUPANTS : ARRAY [ 5 ] (Current Size 2) OCCUPANTS[1] : Pat OCCUPANTS[2] : Terry
When using array binds, PL/SQL enables you to bind each variable to a PL/SQL variable with the following declaration, where TypeName is any unique identifier for the PL/SQL data type and DataType can be specified as CHAR, NCHAR, VARCHAR2, or NVARCHAR2.
TYPETypeNameIS TABLE OFDataType(<precision>) INDEX BY BINARY_INTEGER;
If the variable is declared as array of NUMBER, you can bind it to a PL/SQL variable of the following data types: NUMBER, INTEGER, FLOAT, or DOUBLE PRECISION. To do so, use the appropriate declaration:
TYPETypeNameIS TABLE OF NUMBER INDEX BY BINARY_INTEGER; TYPETypeNameIS TABLE OF INTEGER INDEX BY BINARY_INTEGER; TYPETypeNameIS TABLE OF FLOAT INDEX BY BINARY_INTEGER; TYPETypeNameIS TABLE OF DOUBLE PRECISION INDEX BY BINARY_INTEGER;
The following example declares the occupants VARCHAR2 array, which is then declared and used within a PL/SQL block:
Command> VARIABLE occupants[5] VARCHAR2(15);
Command> SETVARIABLE occupants[1] := 'Pat';
Command> SETVARIABLE occupants[2] := 'Terry';
Command> DECLARE
> TYPE occuname IS TABLE OF VARCHAR2(15) INDEX BY BINARY_INTEGER;
> x occuname;
> BEGIN
> x := :occupants;
> FOR LROW IN x.FIRST..x.LAST LOOP
> x(LROW) := x(LROW) || ' Doe';
> END LOOP;
> :occupants := x;
> END;
> /
PL/SQL procedure successfully completed.
Command> PRINT occupants;
OCCUPANTS : ARRAY [ 5 ] (Current Size 2)
OCCUPANTS[1] : Pat Doe
OCCUPANTS[2] : Terry Doe
When you set autovariables on in ttIsql, TimesTen creates an automatic bind variable named after each column in the last fetched row. An automatic bind variable can be used in the same manner of any bind variable.
The following example selects all rows from the employees table. Since all columns are retrieved, automatic variables are created and named for each column. The bind variable contains the last value retrieved for each column.
Command> SET AUTOVARIABLES ON; Command> SELECT * FROM employees; ... < 204, Hermann, Baer, HBAER, 515.123.8888, 1994-06-07 00:00:00, PR_REP, 10000, <NULL>, 101, 70 > < 205, Shelley, Higgins, SHIGGINS, 515.123.8080, 1994-06-07 00:00:00, AC_MGR, 12000, <NULL>, 101, 110 > < 206, William, Gietz, WGIETZ, 515.123.8181, 1994-06-07 00:00:00, AC_ACCOUNT, 8300, <NULL>, 205, 110 > Command> PRINT; EMPLOYEE_ID : 206 FIRST_NAME : William LAST_NAME : Gietz EMAIL : WGIETZ PHONE_NUMBER : 515.123.8181 HIRE_DATE : 1994-06-07 00:00:00 JOB_ID : AC_ACCOUNT SALARY : 8300 COMMISSION_PCT : <NULL> MANAGER_ID : 205 DEPARTMENT_ID : 110
If you provide an alias for a column name, the automatic bind variable name uses the alias, rather than the column name.
Command> SET AUTOVARIABLES ON; Command> SELECT employee_id ID, First_name SURNAME, last_name LASTNAME FROM employees; ID, SURNAME, LASTNAME ... < 204, Hermann, Baer > < 205, Shelley, Higgins > < 206, William, Gietz > 107 rows found. Command> PRINT; ID : 206 SURNAME : William LASTNAME : Gietz
For any query that fetches data without a known named column, set columnlabels on to show the column names. The following example shows that the columns returns from ttConfiguration built-in procedure are paramname and paramvalue.
Command> SET AUTOVARIABLES ON;
Command> SET COLUMNLABELS ON;
Command> call TTCONFIGURATION('PLSQL');
PARAMNAME, PARAMVALUE
< PLSQL, 1 >
1 row found.
Command> IF :paramvalue = 1 THEN "e:PLSQL is enabled";
PLSQL is enabled
Command> IF NOT :paramvalue = 1 THEN "e:PLSQL is not enabled";
You can also use the describe command to show the column names. The following example uses the describe command to display the column names for the ttConfiguration built-in procedure.
Command> DESCRIBE TTCONFIGURATION;
Procedure TTCONFIGURATION:
Parameters:
PARAMNAME TT_VARCHAR (30)
Columns:
PARAMNAME TT_VARCHAR (30) NOT NULL
PARAMVALUE TT_VARCHAR (1024)
1 procedure found.
You can create and execute PL/SQL blocks from the ttIsql command line.
Set serveroutput on to display results generated fro €ÿm the PL/SQL block:
Command> set serveroutput on
Create an anonymous block that puts a text line in the output buffer. Note that the block must be terminated with a slash (/).
Command> BEGIN
> DBMS_OUTPUT.put_line(
> 'Welcome!');
> END;
> /
Welcome!
PL/SQL procedure successfully completed.
Command>
See the Oracle TimesTen In-Memory Database PL/SQL Developer's Guide for more examples.
You can pass data back to applications from PL/SQL by using OUT parameters. This example returns information about how full a TimesTen database is.
Create the tt_space_info PL/SQL procedure and use SQL to provide values for the permpct, permmaxpct, temppct, and tempmaxpct parameters.
Command> CREATE OR REPLACE PROCEDURE tt_space_info
> (permpct OUT PLS_INTEGER,
> permmaxpct OUT PLS_INTEGER,
> temppct OUT PLS_INTEGER,
> tempmaxpct OUT PLS_INTEGER) AS
> monitor sys.monitor%ROWTYPE;
> BEGIN
> SELECT * INTO monitor FROM sys.monitor;
> permpct := monitor.perm_in_use_size * 100 /
monitor.perm_allocated_size;
> permmaxpct := monitor.perm_in_use_high_water * 100 /
monitor.perm_allocated_size;
> temppct := monitor.temp_in_use_size * 100 /
monitor.temp_allocated_size;
> tempmaxpct := monitor.temp_in_use_high_water * 100 /
monitor.temp_allocated_size;
> END;
>/
Procedure created.
Declare the variables and call tt_space_info. The parameter values are passed back to ttIsql so they can be printed:
Command> VARIABLE permpct NUMBER
Command> VARIABLE permpctmax NUMBER
Command> VARIABLE temppct NUMBER
Command> VARIABLE temppctmax NUMBER
Command> BEGIN
> tt_space_info(:permpct, :permpctmax, :temppct, :temppctmax);
> END;
>/
PL/SQL procedure successfully completed.
Command> PRINT permpct;
PERMPCT : 4
Command> PRINT permpctmax;
PERMPCTMAX : 4
Command> PRINT temppct;
TEMPPCT : 11
Command> PRINT temppctmax;
TEMPPCTMAX : 11
You can also pass back a statement handle that can be executed by a PL/SQL statement with an OUT refcursor parameter. The PL/SQL statement can choose the query associated with the cursor. The following example opens a refcursor, which randomly chooses between ascending or descending order.
Command> VARIABLE ref REFCURSOR;
Command> BEGIN
> IF (mod(dbms_random.random(), 2) = 0) THEN
> open :ref for select object_name from SYS.ALL_OBJECTS order by 1 asc;
> ELSE
> open :ref for select object_name from SYS.ALL_OBJECTS order by 1 desc;
> end if;
> END;
> /
PL/SQL procedure successfully completed.
To fetch the result set from the refcursor, use the PRINT command:
Command> PRINT ref REF : < ACCESS$ > < ALL_ARGUMENTS > < ALL_COL_PRIVS > < ALL_DEPENDENCIES > ... 143 rows found.
Or if the result set was ordered in descending order, the following would print:
Command> PRINT ref REF : < XLASUBSCRIPTIONS > < WARNING_SETTINGS$ > < VIEWS > ... 143 rows found.
The IF-THEN-ELSE command construct enables you to implement conditional branching logic in a ttIsql session. The IF command tests a condition and decides whether to execute commands within the THEN clause or the optional ELSE clause. The commands executed can be SQL statements, SQL scripts, PL/SQL blocks, or TimesTen utilities.
|
Note: For details on the syntax of theIF-THEN-ELSE construct, see the "ttIsql" section in the Oracle TimesTen In-Memory Database Reference. |
The following example creates and tests a bind variable to see if PL/SQL is enabled. It uses the autovariables command to create the bind variable from the result of the call to ttConfiguration. The value can be tested within the IF-THEN-ELSE conditional by testing the paramvalue variable.
|
Note: For more details on theautovariables command, see "Automatically creating bind variables for retrieved columns". |
Command> SET AUTOVARIABLES ON;
Command> CALL TTCONFIGURATION('PLSQL');
PARAMNAME, PARAMVALUE
< PLSQL, 1 >
1 row found.
Command> IF :paramvalue = 1 THEN "e:PLSQL is enabled"
> ELSE "e:PLSQL is not enabled";
PLSQL is enabled
The following example checks to see that the employees table exists. If it does not, it executes the SQL script that creates the employees table; otherwise, a message is printed out.
Command> IF 0 = "SELECT COUNT(*) FROM SYS.TABLES
> WHERE TBLNAME LIKE 'employees';"
> THEN "e:EMPLOYEES table already exists"
> ELSE "@HR_CRE_TT.SQL;";
EMPLOYEES table already exists
There may be a situation where you want to load the results of a SQL query from a back-end Oracle database into a single table on TimesTen without creating a cache grid, cache group, and cache table to contain the results. TimesTen provides the tools that will execute a user-provided SELECT statement on Oracle and load the result set into a table on TimesTen.
The following are the major steps that are performed to accomplish this task:
Create a table with the correct columns and data types on TimesTen.
Provide a SELECT statement that will be executed on Oracle to generate the desired result set.
Load the result set into the table on TimesTen.
TimesTen provides two methods to accomplish these tasks:
The ttIsql utility provides the createandloadfromoraquery command that, once provided the TimesTen table name and the SELECT statement, will automatically create the TimesTen table, execute the SELECT statement on Oracle, and load the result set into the TimesTen table. This command is described fully in "Use ttIsql to create a table and load SQL query results".
The ttTableSchemaFromOraQueryGet built-in procedure evaluates the user-provided SELECT statement to generate a CREATE TABLE statement that can be executed to create a table on TimesTen, which would be appropriate to receive the result set from the SELECT statement. The ttLoadFromOracle built-in procedure executes the SELECT statement on Oracle and loads the result set into the TimesTen table. These built-in procedures are described fully in "Use TimesTen built-in procedures to recommend a table and load SQL query results".
Both methods require the following:
Both the TimesTen and Oracle databases involved must be configured with the same national database character set.
When you connect to the TimesTen database, the connection must contain the same connection attributes that are required when using cache groups, as follows:
The user name, which must be the same on both the TimesTen and Oracle databases
|
Note: The correct privileges must be granted to these users on each database for the SQL statements that will be executed on their behalf. |
The correct passwords for each user as appropriate in the PWD and OraclePWD connection attributes
The OracleServiceName connection attributes that identifies the Oracle database instance
For either method, the user provides the following:
The table name on the TimesTen database where the results of the SQL query will be loaded. If the owner of the table is not provided, the table is created with the current user as the owner. The table name is not required to be the same name as the table name on the Oracle database against which the SQL statement is executed. This table does not require a primary key. If the table already exists, a warning will be issued and the retrieved rows are appended to the table.
Optionally, the number of parallel threads that you would like to be used in parallel when loading the table with the result set. This defaults to four.
The SQL SELECT statement that will be executed against the Oracle database to obtain the required rows. The tables specified within this SELECT statement must be fully qualified, unless the tables are within the schema of the current Oracle user. The query cannot have any parameter bindings.
The SELECT list should contain either simple column references or column aliases. For example, any expressions in the SELECT list should be provided with a column alias. You can also use the column alias to avoid duplication of column names in the result table. For example, instead of using SELECT C1+1 FROM T1, use SELECT C1 + 1 C2 FROM T1, which would create a column named C2.
TimesTen evaluates the SELECT statement and uses the column names, data types, and nullability information to create the table on TimesTen into which the result set will be loaded. The column names and data types (either the same or mapped) are taken from the tables on Oracle involved in the SELECT statement. However, other Oracle table definition information (such as DEFAULT values, primary key, foreign key relationships, and so on) are not used when creating the CREATE TABLE statement for the TimesTen table.
|
Note: If the evaluation returns any unsupported data types or if the query cannot be executed on Oracle, such as from a syntax error, a warning is logged and a comment is displayed for the unsupported column in the output. However, if the data type is not supported by TimesTen, you can cast the data type directly in theSELECT list to a TimesTen supported data type. |
The load process does not check that the column data types and sizes in the TimesTen table match the data types and sizes of the result set. Instead, the insert is attempted and if the column data types cannot be mapped, an error is returned. If the retrieved Oracle data from the SQL query exceeds the TimesTen column size, the data is truncated without a warning.
The load is automatically committed every 256 rows. If an error is encountered during the load, it will terminate the load, but will not roll back any committed transactions. Any errors returned from the Oracle database are reported in the same manner as when using cache groups.
Because you can use these methods to load into an existing TimesTen table, the following lists the restrictions for this situation:
You cannot load into system tables, dictionary tables, temporary tables, detail tables of views, materialized view tables, materialized view log tables, or tables already in a cache group. In addition, you cannot use a synonym for the table name.
If you load the result set into an existing table that is the referencing table (child table) of a foreign key constraint, the constraint will not be validated. As a result, rows that are missing a parent row may be loaded. Instead, you should verify all foreign keys after the table is loaded.
The following sections provide more details on each individual method:
The ttIsql utility provides the createandloadfromoraquery command, which takes a table name, the number of parallel threads, and a SELECT statement that will be executed on Oracle as input parameters. From these parameters, TimesTen performs the following:
Evaluates the SQL query and creates an appropriate table, if not already created, with the provided table name where the columns are those named in the SQL query with the same (or mapped) data types as those in the Oracle database tables from which the resulting data is retrieved.
Loads the results of the SQL query as executed on the Oracle database into this table. The call returns a single number indicating the number of rows loaded. Any subsequent calls to this command append retrieved rows to the table.
|
Note: See thecreateandloadfromoraquery command in "ttIsql" in the Oracle TimesTen In-Memory Database Reference for full details on syntax, requirements, restrictions, and required privileges. |
The following ttIsql example connects providing the DSN, user name, password for the user on TimesTen, and the password for the same user name on the Oracle database. Then, it executes the createandloadfromoraquery command to evaluate the SELECT statement. The employees table is created on TimesTen with the same column names and data types as the columns and data types of the retrieved rows. Then, the table is populated with the result set from Oracle over two parallel threads.
ttisql "DSN=cachedb1_1122;UID=oratt;PWD=timesten;OraclePWD=oracle"
Copyright (c) 1996-2011, Oracle. All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql
connect "DSN=mydb;UID=oratt;PWD=timesten;OraclePWD=oracle";
Connection successful: DSN=mydb;UID=oratt;
DataStore=/timesten/install/info/DemoDataStore/mydb;DatabaseCharacterSet=WE8DEC;
ConnectionCharacterSet=US7ASCII;DRIVER=/timesten/install/lib/libtten.so;
PermSize=40;TempSize=32;TypeMode=0;OracleNetServiceName=inst1;
(Default setting AutoCommit=1)
Command> createandloadfromoraquery employees 2 SELECT * FROM hr.employees;
Mapping query to this table:
CREATE TABLE "ORATT"."EMPLOYEES" (
"EMPLOYEE_ID" number(6,0) NOT NULL,
"FIRST_NAME" varchar2(20 byte),
"LAST_NAME" varchar2(25 byte) NOT NULL,
"EMAIL" varchar2(25 byte) NOT NULL,
"PHONE_NUMBER" varchar2(20 byte),
"HIRE_DATE" date NOT NULL,
"JOB_ID" varchar2(10 byte) NOT NULL,
"SALARY" number(8,2),
"COMMISSION_PCT" number(2,2),
"MANAGER_ID" number(6,0),
"DEPARTMENT_ID" number(4,0)
)
Table employees created
107 rows loaded from oracle.
Execute the DESCRIBE command to show the new table:
|
Note: In this example, the table owner is not specified, so it defaults to the current user. In this example, the current user isoratt. |
Command> DESCRIBE employees;
Table ORATT.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)
1 table found.
(primary key columns are indicated with *)
Command> SELECT * FROM employees;
< 114, Den, Raphaely, DRAPHEAL, 515.127.4561, 2002-12-07 00:00:00, PU_MAN,
11000, <NULL>, 100, 30 >
< 115, Alexander, Khoo, AKHOO, 515.127.4562, 2003-05-18 00:00:00, PU_CLERK,
3100, <NULL>, 114, 30 >
…
< 205, Shelley, Higgins, SHIGGINS, 515.123.8080, 2002-06-07 00:00:00,
AC_MGR, 12008, <NULL>, 101, 110 >
< 206, William, Gietz, WGIETZ, 515.123.8181, 2002-06-07 00:00:00,
AC_ACCOUNT, 8300, <NULL>, 205, 110 >
107 rows found.
The following example uses the createandloadfromoraquery command to create the oratt.emp table on TimesTen and populate it in parallel over four threads with data from the hr.employees table on the Oracle database, where employee_id is less than 200.
Command> createandloadfromoraquery emp 4 SELECT * FROM hr.employees
WHERE employee_id < 200;
Mapping query to this table:
CREATE TABLE "ORATT"."EMP" (
"EMPLOYEE_ID" number(6,0) NOT NULL,
"FIRST_NAME" varchar2(20 byte),
"LAST_NAME" varchar2(25 byte) NOT NULL,
"EMAIL" varchar2(25 byte) NOT NULL,
"PHONE_NUMBER" varchar2(20 byte),
"HIRE_DATE" date NOT NULL,
"JOB_ID" varchar2(10 byte) NOT NULL,
"SALARY" number(8,2),
"COMMISSION_PCT" number(2,2),
"MANAGER_ID" number(6,0),
"DEPARTMENT_ID" number(4,0)
)
Table emp created
100 rows loaded from oracle.
Then, the following createandloadfromoraquery retrieves all employees whose id is > 200 and the result set is appended to the existing table in TimesTen. A warning tells you that the table already exists and that 6 rows were added to it.
Command> createandloadfromoraquery emp 4 SELECT * FROM hr.employees WHERE employee_id > 200; Warning 2207: Table ORATT.EMP already exists 6 rows loaded from oracle.
While the createAndLoadFromOraQuery command automatically performs all of the tasks for creating the TimesTen table and loading the result set from Oracle into it, the following two built-in procedures separate the same functionality into the following two steps:
The ttTableSchemaFromOraQueryGet built-in procedure evaluates the SQL query and generates the CREATE TABLE SQL statement that you can choose to execute. In order to execute this statement, the user should have all required privileges to execute the query on Oracle. This enables you to view the table structure without execution. However, it does require you to execute the recommended CREATE TABLE statement yourself.
The ttLoadFromOracle built-in procedure executes the SQL query on the back-end Oracle database and then loads the result set into the TimesTen table. It requires the TimesTen table name where the results will be loaded, the Oracle SQL SELECT statement to obtain the required rows, and the number of parallel threads that you would like to be used in parallel when loading the table with this result set.
The call returns a single number indicating the number of rows loaded. Any subsequent calls append the retrieved rows to the table.
|
Note: See "ttTableSchemaFromOraQueryGet" and "ttLoadFromOracle" in the Oracle TimesTen In-Memory Database Reference for full details on syntax, requirements, restrictions, and required privileges. |
The following example connects providing the DSN, user name, password for the user on TimesTen, the password for a user with the same name on the Oracle database, and the OracleNetServiceName for the Oracle database instance. Then, it executes the ttTableSchemaFromOraQueryGet built-in procedure to evaluate the SELECT statement and return a recommended CREATE TABLE statement for the employees table. Finally, the example executes the ttLoadFromOracle built-in procedure to load the employees table with the result set from Oracle. The load is performed in parallel over four threads, which is the default.
|
Note: Ifautocommit is set to off, then the user must either commit or rollback manually after loading the table. |
$ ttisql "DSN=mydb;uid=oratt;pwd=timesten;
OraclePwd=oracle;OracleNetServiceName=inst1"
Copyright (c) 1996-2011, Oracle. All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.
connect "DSN=mydb;uid=oratt;pwd=timesten;
OraclePwd=oracle;OracleNetServiceName=inst1";
Connection successful: DSN=mydb;UID=oratt;
DataStore=/timesten/install/info/DemoDataStore/mydb;
DatabaseCharacterSet=WE8DEC;ConnectionCharacterSet=US7ASCII;
DRIVER=/timesten/install/lib/libtten.so;PermSize=40;TempSize=32;
TypeMode=0;OracleNetServiceName=inst1;
(Default setting AutoCommit=1)
Command> call ttTableSchemaFromOraQueryGet('hr','employees',
'SELECT * FROM hr.employees');
< CREATE TABLE "HR"."EMPLOYEES" (
"EMPLOYEE_ID" number(6,0) NOT NULL,
"FIRST_NAME" varchar2(20 byte),
"LAST_NAME" varchar2(25 byte) NOT NULL,
"EMAIL" varchar2(25 byte) NOT NULL,
"PHONE_NUMBER" varchar2(20 byte),
"HIRE_DATE" date NOT NULL,
"JOB_ID" varchar2(10 byte) NOT NULL,
"SALARY" number(8,2),
"COMMISSION_PCT" number(2,2),
"MANAGER_ID" number(6,0),
"DEPARTMENT_ID" number(4,0)
) >
1 row found.
Command> CALL ttLoadFromOracle ('HR','EMPLOYEES','SELECT * FROM HR.EMPLOYEES');
< 107 >
1 row found.
Command> SELECT * FROM hr.employees;
< 100, Steven, King, SKING, 515.123.4567, 2003-06-17 00:00:00, AD_PRES, 24000, <NULL>, <NULL>, 90 >
< 101, Neena, Kochhar, NKOCHHAR, 515.123.4568, 2005-09-21 00:00:00, AD_VP, 17000, <NULL>, 100, 90 >
...
< 205, Shelley, Higgins, SHIGGINS, 515.123.8080, 2002-06-07 00:00:00, AC_MGR, 12008, <NULL>, 101, 110 >
< 206, William, Gietz, WGIETZ, 515.123.8181, 2002-06-07 00:00:00, AC_ACCOUNT, 8300, <NULL>, 205, 110 >
107 rows found.
The following sections describe how to view the query optimizer plans, commands in the SQL command cache, or query plans for commands in the SQL command cache:
The built-in showplan command is used to display the query optimizer plans used by the TimesTen Data Manager for executing queries. In addition, ttIsql contains built-in query optimizer hint commands for altering the query optimizer plan. By using the showplan command in conjunction with the ttIsql commands summarized below, the optimum execution plan can be designed. For detailed information on the TimesTen query optimizer see "The TimesTen Query Optimizer".
optprofile - Displays the current optimizer hint settings and join order.
trytmphash - Enables or disables the use of temporary hash indexes.
trytmptable - Enables or disables the use of an intermediate results table.
trytmprange - Enables or disables the use of temporary range indexes.
When using the showplan command and the query optimizer hint commands the autocommit feature must be turned off. Use ttIsql's autocommit built-in command to turn autocommit off.
The example below shows how these commands can be used to change the query optimizer execution plan.
Command> CREATE TABLE T1 (A NUMBER); Command> CREATE TABLE T2 (B NUMBER); Command> CREATE TABLE T3 (C NUMBER); Command> Command> INSERT INTO T1 VALUES (3); 1 row inserted. Command> INSERT INTO T2 VALUES (3); 1 row inserted. Command> INSERT INTO T3 VALUES (3); 1 row inserted. Command> INSERT INTO T1 VALUES (4); 1 row inserted. Command> INSERT INTO T2 VALUES (5); 1 row inserted. Command> INSERT INTO T3 VALUES (6); 1 row inserted. Command> Command> autocommit 0; Command> showplan; Command> SELECT * FROM T1, T2, T3 WHERE A=B AND B=C AND A=B; Query Optimizer Plan: STEP: 1 LEVEL: 3 OPERATION: TblLkSerialScan TBLNAME: T1 IXNAME: <NULL> INDEXED CONDITION: <NULL> NOT INDEXED: <NULL> STEP: 2 LEVEL: 3 OPERATION: TblLkSerialScan TBLNAME: T2 IXNAME: <NULL> INDEXED CONDITION: <NULL> NOT INDEXED: T1.A = T2.B AND T1.A = T2.B STEP: 3 LEVEL: 2 OPERATION: NestedLoop TBLNAME: <NULL> IXNAME: <NULL> INDEXED CONDITION: <NULL> NOT INDEXED: <NULL> STEP: 4 LEVEL: 2 OPERATION: TblLkSerialScan TBLNAME: T3 IXNAME: <NULL> INDEXED CONDITION: <NULL> NOT INDEXED: T1.A = T3.C AND T2.B = T3.C STEP: 5 LEVEL: 1 OPERATION: NestedLoop TBLNAME: <NULL> IXNAME: <NULL> INDEXED CONDITION: <NULL> NOT INDEXED: <NULL> < 3, 3, 3 > 1 row found. Command> trytbllocks 0; Command> tryserial 0; Command> SELECT * FROM T1, T2, T3 WHERE A=B AND B=C AND A=B; Query Optimizer Plan: STEP: 1 LEVEL: 3 OPERATION: TmpRangeScan TBLNAME: T1 IXNAME: <NULL> INDEXED CONDITION: <NULL> NOT INDEXED: <NULL> STEP: 2 LEVEL: 3 OPERATION: RowLkSerialScan TBLNAME: T2 IXNAME: <NULL> INDEXED CONDITION: <NULL> NOT INDEXED: T1.A = T2.B AND T1.A = T2.B STEP: 3 LEVEL: 2 OPERATION: NestedLoop TBLNAME: <NULL> IXNAME: <NULL> INDEXED CONDITION: <NULL> NOT INDEXED: <NULL> STEP: 4 LEVEL: 2 OPERATION: RowLkSerialScan TBLNAME: T3 IXNAME: <NULL> INDEXED CONDITION: <NULL> NOT INDEXED: T1.A = T3.C AND T2.B = T3.C STEP: 5 LEVEL: 1 OPERATION: NestedLoop TBLNAME: <NULL> IXNAME: <NULL> INDEXED CONDITION: <NULL> NOT INDEXED: <NULL> < 3, 3, 3 > 1 row found. Command>
In this example a query against three tables is executed and the query optimizer pla÷@¿n is displayed. The first version of the query simply uses the query optimizer's default execution plan. However, in the second version the trytbllocks and tryserial ttIsql built-in hint commands have been used to alter the query optimizer's plan. Instead of using serial scans and nested loop joins the second version of the query uses temporary index scans, serial scans and nested loops.
In this way the showplan command in conjunction with ttIsql's built-in query optimizer hint commands can be used to quickly determine which execution plan should be used to meet application requirements.
The following sections describe how to view commands and their explain plans:
The ttIsql cmdcache command invokes the ttSqlCmdCacheInfo built-in procedure to display the contents of the TimesTen SQL Command Cache. See "Displaying commands stored in the SQL Command Cache" for full details on this procedure.
If you execute the cmdcache command without parameters, the full SQL Command Cache contents are displayed. Identical to the ttSqlCmdCacheInfo built-in procedure, you can provide a command ID to specify a specific command to be displayed.
In addition, the ttIsql cmdcache command can filter the results so that only those commands that match a particular owner or query text are displayed.
The syntax for the cmdcache command is as follows:
cmdcache [[by {sqlcmdid | querytext | owner}] <query_substring>
If you provide the owner parameter, the results are filtered by the owner, identified by the <query_substring>, displayed within each returned command. If you provide the querytext parameter, the results are filtered so that all queries are displayed that contain the substring provided within the <query_substring>. If only the <query_substring> is provided, such as cmdcache <query_substring>, the command assumes to filter the query text by the <query_substring>.
The ttIsql explain command displays the query plan for an individual command.
If you provide a command ID from the SQL Command Cache, the explain command invokes the ttSqlCmdQueryPlan built-in procedure to display the query plan for an individual command in the TimesTen SQL Command Cache. If you want the explain plan displayed in a formatted method, execute the explain command instead of calling the ttSqlCmdQueryPlan built-in procedure. Both provide the same information, but the ttSqlCmdQueryPlan built-in procedure provides the data in a raw data format. See "Viewing query plans associated with commands stored in the SQL Command Cache" for full details on the ttSqlCmdQueryPlan built-in procedure.
If you provide a SQL statement or the history item number, the explain command executes the SQL statements necessary to display the explain plan for this particular SQL statement.
The syntax for the explain command is as follows:
explain [plan for] {[<Connid>.]<ttisqlcmdid> | sqlcmdid <sqlcmdid> | <sqlstmt>
| !<historyitem>}
Identical to the ttSqlCmdQueryPlan built-in procedure, you can provide a command ID to specify a specific command to be displayed. The command ID can be retrieved with the cmdcache command, as described in "View commands in the SQL Command Cache".
The following example provides an explain plan for command ID 38001456:
Command> EXPLAIN SQLCMDID 38001456; Query Optimizer Plan: Query Text: select * from all_objects where object_name = 'DBMS_OUTPUT' STEP: 1 LEVEL: 12 OPERATION: TblLkRangeScan TABLENAME: OBJ$ TABLEOWNERNAME: SYS INDEXNAME: USER$.I_OBJ INDEXEDPRED: NONINDEXEDPRED: (RTRIM( NAME )) = DBMS_OUTPUT;NOT( 10 = TYPE#) ; ( FLAGS ^ 128 = 0) ; STEP: 2 LEVEL: 12 OPERATION: RowLkRangeScan TABLENAME: OBJAUTH$ TABLEOWNERNAME: SYS INDEXNAME: OBJAUTH$.I_OBJAUTH1 INDEXEDPRED: ( (GRANTEE#=1 ) OR (GRANTEE#=10 ) ) AND ( (PRIVILEGE#=8 ) ) NONINDEXEDPRED: OBJ# = OBJ#; STEP: 3 LEVEL: 11 OPERATION: NestedLoop(Left OuterJoin) TABLENAME: TABLEOWNERNAME: INDEXNAME: INDEXEDPRED: NONINDEXEDPRED: ... STEP: 21 LEVEL: 1 OPERATION: Project TABLENAME: TABLEOWNERNAME: INDEXNAME: INDEXEDPRED: NONINDEXEDPRED: Command>
In addition, the ttIsql explain command can generate an explain plan for any SQL query you provide. For example, the following shows the explain plan for SQL query "SELECT * FROM DUAL;"
Command> EXPLAIN SELECT * FROM DUAL; Query Optimizer Plan: STEP: 1 LEVEL: 1 OPERATION: RowLkSerialScan TBLNAME: DUAL IXNAME: <NULL> INDEXED CONDITION: <NULL> NOT INDEXED: <NULL>
You can also retrieve explain plans based upon the command history. The following example shows how you explain a previously executed SQL statement using the history command ID:
Command> SELECT * FROM all_objects WHERE object_name = 'DBMS_OUTPUT'; < SYS, DBMS_OUTPUT, <NULL>, 241, <NULL>, PACKAGE, 2009-10-13 10:41:11, 2009-10-13 10:41:11, 2009-10-13:10:41:11, VALID, N, N, N, 1, <NULL> > < PUBLIC, DBMS_OUTPUT, <NULL>, 242, <NULL>, SYNONYM, 2009-10-13 10:41:11, 2009-10-13 10:41:11, 2009-10-13:10:41:11, INVALID, N, N, N, 1, <NULL> > < SYS, DBMS_OUTPUT, <NULL>, 243, <NULL>, PACKAGE BODY, 2009-10-13 10:41:11, 2009-10-13 10:41:11, 2009-10-13:10:41:11, VALID, N, N, N, 2, <NULL> > 3 rows found. Command> HISTORY; 1 connect "DSN=cache"; 2 help cmdcache; 3 cmdcache; 4 explain select * from dual; 5 select * from all_objects where object_name = 'DBMS_OUTPUT'; Command> EXPLAIN !5; Query Optimizer Plan: STEP: 1 LEVEL: 10 OPERATION: TblLkRangeScan TBLNAME: SYS.OBJ$ IXNAME: USER$.I_OBJ INDEXED CONDITION: <NULL> NOT INDEXED: O.FLAGS & 128 = 0 AND CAST(RTRIM (O.NAME) AS VARCHAR2(30 BYTE) INLINE) = 'DBMS_OUTPUT' AND O.TYPE# <> 10 STEP: 2 LEVEL: 10 OPERATION: RowLkRangeScan TBLNAME: SYS.OBJAUTH$ IXNAME: OBJAUTH$.I_OBJAUTH1 INDEXED CONDITION: (OA.GRANTEE# = 1 OR OA.GRANTEE# = 10) AND OA.PRIVILEGE# = 8 NOT INDEXED: OA.OBJ# = O.OBJ# STEP: 3 LEVEL: 9 OPERATION: NestedLoop(Left OuterJoin) TBLNAME: <NULL> IXNAME: <NULL> INDEXED CONDITION: <NULL> NOT INDEXED: <NULL> STEP: 4 LEVEL: 9 OPERATION: TblLkRangeScan TBLNAME: SYS.OBJAUTH$ IXNAME: OBJAUTH$.I_OBJAUTH1 INDEXED CONDITION: (OBJAUTH$.GRANTEE# = 1 OR OBJAUTH$.GRANTEE# = 10) AND (OBJAUTH$.PRIVILEGE# = 2 OR OBJAUTH$.PRIVILEGE# = 3 OR OBJAUTH$.PRIVILEGE# = 4 OR OBJAUTH$.PRIVILEGE# = 5 OR OBJAUTH$.PRIVILEGE# = 8) NOT INDEXED: O.OBJ# = OBJAUTH$.OBJ# ... STEP: 19 LEVEL: 1 OPERATION: NestedLoop(Left OuterJoin) TBLNAME: <NULL> IXNAME: <NULL> INDEXED CONDITION: <NULL> NOT INDEXED: O.OWNER# = 1 OR (O.TYPE# IN (7,8,9) AND (NOT( ISNULLROW (SYS.OBJAUTH$.ROWID)) OR NOT( ISNULLROW (SYS.SYSAUTH$.ROWID)))) OR (O.TYPE# IN (1,2,3,4,5) AND NOT( ISNULLROW (SYS.SYSAUTH$.ROWID))) OR (O.TYPE# = 6 AND NOT( ISNULLROW (SYS.SYSAUTH$.ROWID))) OR (O.TYPE# = 11 AND NOT( ISNULLROW (SYS.SYSAUTH$.ROWID))) OR (O.TYPE# NOT IN (7,8,9,11) AND NOT( ISNULLROW (SYS.OBJAUTH$.ROWID))) OR (O.TYPE# = 28 AND NOT( ISNULLROW (SYS.SYSAUTH$.ROWID))) OR (O.TYPE# = 23 AND NOT( ISNULLROW (SYS.SYSAUTH$.ROWID))) OR O.OWNER# = 10
You can perform the following on ODBC functions within ttIsql:
The ttIsql command attempts to cancel an ongoing ODBC function when the user presses Ctrl-C.
Information on the time required to execute common ODBC function calls can be displayed by using the ttIsql timing command. When the timing feature is enabled many built-in ttIsql commands will report the elapsed execution time associated with the primary ODBC function call corresponding to the ttIsql command that is executed.
For example, when executing the ttIsql connect command several ODBC function calls are executed, however, the primary ODBC function call associated with connect is SQLDriverConnect and this is the function call that is timed and reported as shown below.
Command> timing 1; Command> connect "DSN=MY_DSN"; Connection successful: DSN=MY_DSN;DataStore=E:\ds\MY_DSN; DRIVER=E:\WINNT\System32\ TTdv1122.dll; (Default setting AutoCommit=1) Execution time (SQLDriverConnect) = 1.2626 seconds. Command>
In the example above, the SQLDriverConnect call took about 1.26 seconds to execute.
When using the timing command to measure queries, the time required to execute the query plus the time required to fetch the query results is measured. To avoid measuring the time to format and print query results to the display, set the verbosity level to 0 before executing the query.
Command> timing 1; Command> verbosity 0; Command> SELECT * FROM T1; Execution time (SQLExecute + FetchLoop) = 0.064210 seconds. Command>
Execute the WHENEVER SQLERROR command to prescribe what to do when a SQL error occurs. WHENEVER SQLERROR can be used to set up a recovery action for SQL statements, SQL script, or PL/SQL block.
By default, if a SQL error occurs while in ttIsql, the error information is displayed and ttIsql continues so that you can enter a new command. The default setting is WHENEVER SQLERROR CONTINUE NONE. You can also specify that ttIsql exits each time an error occurs, which may not be the best action for interactive use or when executing a SQL script or a PL/SQL block.
|
Note: For syntax of theWHENEVER SQLERROR command, see the "ttIsql" section in the Oracle TimesTen In-Memory Database Reference. |
The following example uses EXIT to return an error code of 255 and executes a COMMIT statement to save all changes to the current connection before exiting ttIsql. The example retrieves the error code using the C shell echo $status command.
Command> WHENEVER SQLERROR EXIT 255 COMMIT; Command> SELECT emp_id FROM employee; 2206: Table PAT.EMPLOYEE not found WHENEVER SQLERROR exiting. $ echo $status 255
The following example demonstrates how the WHENEVER SQLERROR command can execute ttIsql commands or TimesTen utilities when an error occurs, even if the error is from another TimesTen utility:
Command> WHENEVER SQLERROR EXEC "DSSIZE;CALL TTSQLCMDCACHEINFOGET();"; Command> CALL TTCACHEPOLICYGET; 5010: No OracleNetServiceName specified in DSN The command failed. DSSIZE; PERM_ALLOCATED_SIZE: 32768 PERM_IN_USE_SIZE: 9204 PERM_IN_USE_HIGH_WATER: 9204 TEMP_ALLOCATED_SIZE: 40960 TEMP_IN_USE_SIZE: 7785 TEMP_IN_USE_HIGH_WATER: 7848 CALL TTSQLCMDCACHEINFOGET(); CMDCOUNT, FREEABLECOUNT, SIZE < 10, 7, 41800 > 1 row found.
The following demonstrates the SUPPRESS command option. It suppresses all error messages and continues to the next command. The example shows that the error messages can be turned back on in the existing connection with another command option, which in this case is the EXIT command.
Command> WHENEVER SQLERROR SUPPRESS;
Command> SELECT *;
Command> WHENEVER SQLERROR EXIT;
Command> SELECT *;
1001: Syntax error in SQL statement before or at: "", character position: 9
select *
^
WHENEVER SQLERROR exiting.
The following example sets a bind variable called retcode, the value of which is returned when a SQL error occurs:
Command> VARIABLE retcode NUMBER := 111;
Command> WHENEVER SQLERROR EXIT :retcode;
Command> INSERT INTO EMPLOYEES VALUES (
> 202, 'Pat', 'Fay', 'PFAY', '603.123.6666',
> TO_DATE ('17-AUG-1997', 'DD-MON-YYYY'),
> 'MK_REP', 6000, NULL, 201, 20);
907: Unique constraint (EMPLOYEES on PAT.EMPLOYEES) violated at Rowid
<BMUFVUAAACOAAAAIiB>
WHENEVER SQLERROR exiting.
$ echo $status;
111
This section summarizes the new features and functionality of Oracle TimesTen In-Memory Database Release 11.2.2 that are documented in this guide, providing links into the guide for more information.
A new tool, the Index Advisor, can be used to recommend a set of indexes that could improve the performance of a specific SQL workload. For more details, see "Using the Index Advisor to recommend indexes".
New tools have been added that enable you to load the results of a SQL query from a back-end Oracle database into a single table on TimesTen without creating a cache grid, cache group, and cache table to contain the results. TimesTen provides the tools that will execute a user provided SELECT statement on Oracle and load the result set into a table on TimesTen. For more information, see "Loading Oracle data into a TimesTen table".
You can defragment a TimesTen database with the ttMigrate utility. For full details, see "Defragmenting TimesTen databases".
To defragment multiple databases with minimal overall service downtime, use a combination of the ttMigrate and ttRepAdmin -duplicate utilities to defragment TimesTen databases that are involved in an active standby pair replication scheme. For details, see "Online defragmentation of TimesTen databases".
You can now declare, use, and set bind variables within ttIsql with the variable and setvariable commands. In addition, automatic bind variables can also be created. See "Using, declaring, and setting variables" for more details.
You can cancel an ODBC function with Ctrl-C. See "Canceling ODBC functions" for more details.
Use the WHENEVER SQLERROR command to control error recovery within ttIsql. For more details, see "Error recovery with WHENEVER SQLERROR".
Use the IF-THEN-ELSE command construct to to implement conditional branching logic in a ttIsql session. See "Conditional control with the IF-THEN-ELSE command construct" for more details.
It is important to verify at frequent intervals that there are no transaction log holds that could result in an excessive accumulation of transaction log files. If too many transaction log files accumulate and fill up available disk space, new transactions in the TimesTen database cannot begin until the transaction log hold is advanced and transaction log files are purged by the next checkpoint operation. See "Monitoring accumulation of transaction log files" for more details.
The LOB data type is now supported. See "SQL string and character functions" for more details.
Range indexes used to be referred to as T-tree indexes. Now all output and commands use range as the identifying terminology. In "Viewing and changing query optimizer plans", the showplan command now takes tryrange and trytmprange as options and the output for the query plan shows range indexes, such as TmpRangeScan.
There is a new tablesize command within ttIsql that shows the actual sizes of tables within the TimesTen database. For full details, see "Using the ttIsql tablesize command".
The TimesTen Access Control provides authentication for each user and authorization for all objects in the database. Authentication is provided with the correct user password. Management of authorization for all objects in the database is provided by granting appropriate privileges to specific users.
The following sections describe the TimesTen authentication and authorization:
For users to access and manipulate data within the database, you must create users and provide appropriate passwords. When you create a user, you should also grant the appropriate privileges for connecting to the database or for access to objects in the database. For more information on granting privileges, see "Providing authorization to objects through privileges".
The following sections describe how to create and manage your users:
There are three types of users in the TimesTen database:
Instance administrator: The instance administrator is the user who installed the TimesTen instance. This user has full privileges for everything within the TimesTen instance. For information on creating this user, see "TimesTen Installation" in the Oracle TimesTen In-Memory Database Installation Guide.
|
Note: In addition to the instance administrator, there are four system users created during the TimesTen install. These system users are used internally by TimesTen as follows:SYSTEM for internal use, SYS for system objects, GRID for cache grid objects and TTREP for replication objects. |
Internal user: An internal user is created within TimesTen for use within the TimesTen database. An internal user authenticates with a password for a particular database in which it was defined.
TimesTen user names are case-insensitive, of type TT_CHAR and limited to 30 characters. For details on all user naming conventions, see "Names, Namespace and Parameters" in the Oracle TimesTen In-Memory Database SQL Reference.
You can create an internal user with the CREATE USER statement, which is described in the CREATE USER section in the Oracle TimesTen In-Memory Database SQL Reference.
External user: An external user is created within the operating system. External users are assumed to have been authenticated by the operating system at login time, so there is no stored password within the database. One cannot connect as an external user from a different host from which the TimesTen database is installed. On the same host, we use the operating system credentials of the client to enable the client to connect as that particular external user. For example, if an external user logs into the UNIX system, they can connect to the TimesTen database without specifying a password since they already provided it during the login, as long as the external user has been granted the correct privileges. The external user must also be in the TimesTen users group and have the correct permissions granted to it, as described in the Oracle TimesTen In-Memory Database Installation Guide.
You cannot connect with an external user defined on one host to a TimesTen data source on a remote host. External users can only be used to connect to the local TimesTen data source, because the local operating system authenticates the external user. When connecting over a client/server connection, the external user must be defined on the same host the client and server. Thus, in when using an external user, both the client and the server must be on the same host since the operating system provides the authentication of the user.
While the external user is created within the operating system, you still need to identify the user to the database as an external user with the IDENTIFIED EXTERNALLY clause of the CREATE USER statement. For details on this SQL statement, see "CREATE USER" in the Oracle TimesTen In-Memory Database SQL Reference.
UNIX external user names are case sensitive. Windows external user names are not. When connecting from UNIX platforms, TimesTen automatically converts the external user name to upper case, rendering it case insensitive.
If you do not want to use cleartext passwords to log into TimesTen, then use the PWDCrypt attribute to create a hash of the password. The only reason to use this attribute is if the password is used for logging into other entities, such as an Oracle Database. The PWDCrypt version of the password can always be used to connect to TimesTen, but you cannot convert it back to the original password in order to connect to Oracle.
|
Note: Both the instance administrator and all external users must be in the TimesTen users group specified during the install. For more details, see "TimesTen Installation" in the Oracle TimesTen In-Memory Database Installation Guide. |
Only the instance administrator or a user with the ADMIN privilege can create the internal user or identify the external user with the CREATE USER statement. For security purposes, you can only create or alter the internal user with the CREATE USER or ALTER USER statements using a direct connection to the TimesTen database. Thus, executing CREATE USER or ALTER USER from a client-server application or through passthrough execution is not allowed. You can use the ALTER USER statement to change a user from an internal to an external user or from an external to an internal user. The full syntax for the CREATE USER statement is detailed in the "SQL Statements" chapter in the Oracle TimesTen In-Memory Database SQL Reference.
To create an internal user, provide the user name and password in the CREATE USER statement. The following example creates the internal user TERRY with the password "secret":
CREATE USER TERRY IDENTIFIED BY "secret"; User created.
To identify an external user, provide the user name in the CREATE USER IDENTIFIED EXTERNALLY statement. The following example identifies the external user PAT to the TimesTen database:
CREATE USER PAT IDENTIFIED EXTERNALLY; User created.
To change the external user PAT to an internal user, perform the following ALTER USER statement:
ALTER USER PAT IDENTIFIED BY "secret";
To change the internal user PAT to an external user, perform the following ALTER USER statement:
ALTER USER PAT IDENTIFIED EXTERNALLY;
You can see what users have been created by executing a SELECT statement on the following system views:
SYS.ALL_USERS lists all users of the database that are visible to the current user.
SYS.USER_USERS describes the current user of the database.
SYS.DBA_USERS describes all users of the database. To perform a select statement on this view, you must have the appropriate privileges granted.
For example, to see the current user, perform the following:
SELECT * FROM sys.user_users; < PAT, 4, OPEN, <NULL>, <NULL>, USERS, TEMP, 2009-02-25 12:00:17.027100, <NULL>, <NULL> > 1 row found.
For more details on these views, see "System Tables" in the Oracle TimesTen In-Memory Database System Tables and Views Reference.
Only the internal user has a password that can be modified within the database. A user can alter their own password. A user with the ADMIN privilege can alter the password of any user. These users can change the password with the IDENTIFIED BY clause of the ALTER USER statement.
For example, to change the password for internal user TERRY to "12345" from its current setting, perform the following:
ALTER USER TERRY IDENTIFIED BY "12345"; User altered.
If granted the appropriate privileges, you can use the DROP USER statement to drop users created in the database. You cannot drop the user in the following instances:
You cannot drop the instance administrator.
You cannot drop a user unless all objects owned by that user have first been deleted.
You cannot drop a user if the user is currently connected to the database.
The following DROP USER statement drops the user TERRY from the database:
Command> drop user terry; User dropped.
The following error occurs if you try to drop the instance administrator:
Command> drop user instadmin; 15103: System-defined users and roles cannot be dropped The command failed.
The following error occurs if user Pat tries to drop user Terry when Pat does not have the required ADMIN privilege:
Command> drop user terry; 15100: User PAT lacks privilege ADMIN The command failed.
|
Note: Currently, we do not supportDROP USER CASCADE. |
When multiple users can access database objects, authorization can be controlled to these objects with privileges. Every object has an owner. Privileges control if a user can modify an object owned by another user. Privileges are granted or revoked either by the instance administrator, a user with the ADMIN privilege or, for privileges to a certain object, by the owner of the object.
The following sections describe authorization to objects through the use of privileges:
Granting or revoking multiple privileges with a single SQL statement
Privileges needed for utilities, built-in procedures and first connection attributes
TimesTen provides user authorization to objects in the database through privileges. Users must be granted privileges for access to database resources or objects. These privileges restrict what operations users may perform on those objects. A user has all privileges on all objects in their own schema, and these privileges cannot be revoked. A user can be granted privileges for objects in other users' schemas.
TimesTen evaluates each user's privileges when the SQL statement is executed. Each SQL statement can be executed by an arbitrary user. For example:
SELECT * from PAT.TABLE1;
If this statement is executed by Pat, then no extra privileges are necessary because Pat owns this object. However, if another user, such as Terry, executes this statement, then Terry must have been granted the SELECT privilege for PAT.TABLE1.
Privileges provide the following:
Define what data users, applications, or functions can access or what operations they can perform.
Prevent users from adversely affecting system performance or from consuming excessive system resources. For example, a privilege restricting the creation of indexes is provided not because of an authorization concern, but because it may affect DML performance and occupies space.
Some examples of privileges include the right to perform the following:
Connect to the database and create a session
Create a table
Select rows from a table that is owned by another user
Perform any cache group operation
In addition, a user may need certain privileges in order to perform the following:
Execute certain TimesTen built-in procedures, which are documented in the Oracle TimesTen In-Memory Database Reference.
Execute certain TimesTen command-line utilities, which are documented in the Oracle TimesTen In-Memory Database Reference.
Initiate a connection with first connection attributes, which are documented in the Oracle TimesTen In-Memory Database Reference.
The privilege required for executing each SQL statement is documented in the statement description in the Oracle TimesTen In-Memory Database SQL Reference
There are two levels of privileges:
System privileges: These privileges enable system-wide functionality, such as access to all objects. Granting system privileges can enable a user to perform standard administrator tasks or access to objects in other users' schemas. These privileges extend beyond a single object. Restrict them only to trusted users.
Object privileges: Each type of object has privileges associated with it.
A subset of these privileges are automatically granted to each user upon creation through the PUBLIC role. Privilege hierarchy rules apply to all privileges granted to a user.
Grant privileges to users so that they can accomplish tasks required for their job. We recommend that you are intentional about who you grant privileges, so that they have only the exact privileges that they need to perform necessary operations.
Privileges are checked at prepare time and when the statement is first executed for each SQL statement. Subsequent executions of that statement require further privilege checks only when a revoke operation is executed in the database.
A system privilege enables a user the ability to perform system-level activities across multiple objects in the database. It confers the right to perform a particular operation in the database or to perform an operation on a type of object. For example, the privilege to create or modify an object in another user's schema in the database requires a system privilege to be granted to the user.
Only the instance administrator or a user with the ADMIN privilege can grant a system privilege to a user. The instance administrator always has full system and object privileges, which cannot be revoked at any time.
|
Note: The instance administrator can perform all operations. So, any operation that can be performed by a user withADMIN privileges can also be performed by the instance administrator. |
Some of the system privileges include ADMIN, SELECT ANY TABLE, CREATE SESSION and CREATE ANY SEQUENCE. For more details on granting or revoking system privileges, see "Granting or revoking system privileges".
An object privilege enables a user to perform defined operations on a specific object. Separate object privileges are available for each object type.
Every object owner has access and full privileges to their own objects. A user does not have access to objects owned by other users unless explicitly granted access by the object's owner or by a user with ADMIN privilege. If the PUBLIC role has been granted access to a given object, then all database users have access to that object. A user with ADMIN privileges cannot revoke an owner's privileges on the owner's object.
Object access control requires that a user either be the owner of an object or granted the appropriate object privilege to perform operations on the object. Object privileges are granted or revoked by the instance administrator, a user with the ADMIN privilege or the user who is the owner of the object.
For more details on granting or revoking object privileges, see "Granting or revoking object privileges".
A role called PUBLIC is automatically created in each TimesTen database. By default, TimesTen grants specific privileges to this role. Every user created within the TimesTen database are granted each privilege that is granted to the PUBLIC role. That is, when the instance administrator or a user with the ADMIN privilege creates a user, the privileges associated with the PUBLIC role are granted to each of these users. Each subsequent privilege that is granted to the PUBLIC role is also automatically granted to all users simultaneously. A user with the ADMIN privilege can add or remove default privileges for all users by granting or revoking privileges from the PUBLIC role. When the user revokes a privilege from PUBLIC, it is revoked from each user, except for those users who have this privilege granted to them explicitly.
|
Note: The only exception to this behavior is that any privileges that were granted toPUBLIC by user SYS cannot be revoked. The privileges that were granted as part of database creation are shown when you execute the following SQL statement:
SELECT * FROM DBA_TAB_PRIVS WHERE GRANTOR = 'SYS' |
In the following example, user Pat is granted the SELECT ANY TABLE privilege and PUBLIC is granted the SELECT ANY TABLE privilege. Then, all system privileges are displayed from the SYS.DBA_SYS_PRIVS view. For more information on this view, see "Viewing user privileges". Revoking SELECT ANY TABLE from PUBLIC does not remove SELECT ANY TABLE from Pat, which is shown again through the SYS.DBA_SYS_PRIVS view.
Command> GRANT SELECT ANY TABLE TO PAT; Command> GRANT SELECT ANY TABLE TO PUBLIC; Command> SELECT * FROM SYS.DBA_SYS_PRIVS; < SYS, ADMIN, NO > < PUBLIC, SELECT ANY TABLE, NO > < SYSTEM, ADMIN, NO > < PAT, ADMIN, NO > < PAT, SELECT ANY TABLE, NO > 5 rows found. Command> REVOKE SELECT ANY TABLE FROM PUBLIC; Command> select * from sys.dba_sys_privs; < SYS, ADMIN, NO > < SYSTEM, ADMIN, NO > < PAT, ADMIN, NO > < PAT, SELECT ANY TABLE, NO > 4 rows found.
If you must, you may create a database that grants the ADMIN privilege to PUBLIC. This grants the ADMIN privilege to all users who will then have unrestricted access to all database objects and be able to perform administrative tasks except for tasks that must be performed by the instance administrator. This is never recommended as a long-term approach, since it results in an insecure database. See "TimesTen Upgrades" in the Oracle TimesTen In-Memory Database Installation Guide for full details on when and for what purposes to use this approach.
|
Note: For a full description of the default privileges assigned to thePUBLIC role, see "The PUBLIC role" in the Oracle TimesTen In-Memory Database SQL Reference. |
The PUBLIC role also grants access to certain objects, system tables and views. By default, in a newly created TimesTen database, PUBLIC has SELECT and EXECUTE privileges on various system tables and views and PL/SQL functions, procedures and packages. You can see the list of privileges granted to PUBLIC, and subsequently all users, by querying the SYS.DBA_TAB_PRIVS view. In the following query, the privilege granted to PUBLIC is in the fifth column.
Command> DESC SYS.DBA_TAB_PRIVS;
View SYS.DBA_TAB_PRIVS:
Columns:
GRANTEE VARCHAR2 (30) INLINE
OWNER VARCHAR2 (30) INLINE
TABLE_NAME VARCHAR2 (30) INLINE
GRANTOR VARCHAR2 (30) INLINE
PRIVILEGE VARCHAR2 (40) INLINE NOT NULL
GRANTABLE VARCHAR2 (3) INLINE NOT NULL
HIERARCHY VARCHAR2 (3) INLINE NOT NULL
1 view found.
Command> SELECT * FROM SYS.DBA_TAB_PRIVS WHERE GRANTEE='PUBLIC';
< PUBLIC, SYS, TABLES, SYS, SELECT, NO, NO >
< PUBLIC, SYS, COLUMNS, SYS, SELECT, NO, NO >
< PUBLIC, SYS, INDEXES, SYS, SELECT, NO, NO >
< PUBLIC, SYS, USER_COL_PRIVS, SYS, SELECT, NO, NO >
< PUBLIC, SYS, PUBLIC_DEPENDENCY, SYS, SELECT, NO, NO >
< PUBLIC, SYS, USER_OBJECT_SIZE, SYS, SELECT, NO, NO >
< PUBLIC, SYS, STANDARD, SYS, EXECUTE, NO, NO >
< PUBLIC, SYS, UTL_IDENT, SYS, EXECUTE, NO, NO >
< PUBLIC, SYS, TT_DB_VERSION, SYS, EXECUTE, NO, NO >
< PUBLIC, SYS, PLITBLM, SYS, EXECUTE, NO, NO >
< PUBLIC, SYS, DBMS_OUTPUT, SYS, EXECUTE, NO, NO >
< PUBLIC, SYS, DBMS_SQL, SYS, EXECUTE, NO, NO >
< PUBLIC, SYS, DBMS_STANDARD, SYS, EXECUTE, NO, NO >
< PUBLIC, SYS, DBMS_PREPROCESSOR, SYS, EXECUTE, NO, NO >
< PUBLIC, SYS, UTL_RAW, SYS, EXECUTE, NO, NO >
< PUBLIC, SYS, DBMS_UTILITY, SYS, EXECUTE, NO, NO >
< PUBLIC, SYS, DBMS_RANDOM, SYS, EXECUTE, NO, NO >
...
57 rows found.
There is a hierarchy for all of the privileges. The higher level privileges confer related lower level privileges. For example, the ADMIN privilege confers all privileges. The SELECT ANY TABLE privilege confers the SELECT privilege on any individual table.
Whenever a user needs a privilege for an operation, you can verify if the user already has the privilege if either the user is the owner of the object or has a higher level privilege that confers the necessary privileges for that operation. For example, if the user Pat needs to have the SELECT privilege for Terry.Table2, you can check the following:
Is Pat the owner of the object? If so, owners have all object privileges on their objects
Has Pat been granted the SELECT ANY TABLE privilege? This privilege means Pat would have SELECT ON any table, view, or materialized view.
Has Pat been granted the ADMIN privilege, which would mean that Pat can perform any valid SQL operation.
If you grant a privilege that is included in a higher level privilege, no error occurs. However, when you revoke privileges, they must be revoked in the same unit as granted. The following sequence of grant and revoke statements for user PAT grants the ability to update any table as well as an update privilege on a specific table:
GRANT UPDATE ANY TABLE TO PAT; GRANT UPDATE ON HR.employees TO PAT; REVOKE UPDATE ON HR.employees FROM PAT;
The UPDATE ANY TABLE privilege grants the ability to update any table in the database. The second grant is specific for UPDATE privilege to the HR.employees table. The second grant is unnecessary as the UPDATE ANY TABLE provides access to all tables, including employees, but it does not result in an error. You can revoke the second grant, but it will not affect the first grant of the UPDATE ANY TABLE system privilege. Thus, Pat can still update the HR.employees table.
You must revoke in the same unit as was granted. The following example gr €ÿants the UPDATE ANY TABLE system privilege to Pat. A user tries to revoke the ability to update the HR.employees table from the user. But, the UPDATE ANY TABLE privilege is a system privilege and the UPDATE privilege is an object privilege. The execution of the REVOKE statement for a unit that was not granted fails with an error.
GRANT UPDATE ANY TABLE TO PAT; REVOKE UPDATE ON HR.employees FROM PAT; 15143: REVOKE failed: User PAT does not have object privilege UPDATE on HR.EMPLOYEES The command failed.
The full details of the privilege hierarchy is described in the "Privilege hierarchy" section in the Oracle TimesTen In-Memory Database SQL Reference.
To grant or revoke a system privilege, use the GRANT or REVOKE statements. Only the instance administrator or a user with the ADMIN privilege can grant or revoke system privileges. The GRANT or REVOKE syntax for system privileges includes the system privilege and the user who receives that privilege. Both the syntax for the GRANT and REVOKE statements and the required privileges for executing each SQL statement are described in the "SQL Statements" chapter in the Oracle TimesTen In-Memory Database SQL Reference.
|
Note: How to grant and revoke object privileges is described in "Granting or revoking object privileges". |
The most powerful system privilege is ADMIN. When you grant a user the ADMIN privilege, you enable this user to perform any operation for any database object.
An individual user can view their own system privileges in the SYS.USER_SYS_PRIVS system view. A user with the ADMIN privilege can view all system privileges for all users in the SYS.DBA_SYS_PRIVS system table. These system views are described in "Viewing user privileges".
The following sections describe some of the system privileges available in TimesTen:
|
Note: For a full list of all system privileges, see "Privileges" in the Oracle TimesTen In-Memory Database SQL Reference. |
The ADMIN privilege confers all system and object privileges, which allows these users to perform all administrative tasks and valid database operations. For all objects, a user with the ADMIN privilege can perform create, alter, drop, select, update, insert, or delete operations. In addition, a user with the ADMIN privilege can perform replication tasks, checkpointing, backups, migration, user creation and deletion, and so on. Only a user with the ADMIN privilege can grant or revoke all privileges.
Only a user with the ADMIN privilege may view all system tables and views by default. Only a user with the ADMIN privilege can create, alter or drop replication schemas or active standby pairs. The following views and packages can only be accessed by users with the ADMIN privilege:
|
Note: For more information on viewing privileges for users from system tables or views, see "Viewing user privileges". |
To grant the ADMIN privilege to the user TERRY, execute the following statement:
GRANT ADMIN TO TERRY;
If you have the ADMIN privilege, then you can grant privileges to other users. For example, a user with the ADMIN privilege can grant the SELECT privilege to TERRY on the departments table owned by Pat, as follows:
GRANT SELECT ON PAT.departments TO TERRY;
|
Note: Since Pat is the owner of departments, Pat may also grant theSELECT object privilege to Terry. |
The ALL PRIVILEGES grants every system privilege to a user. If you want a user to have most of the system privileges, you can grant ALL PRIVILEGES to a user and then revoke only those system privileges that you do not want them to have. The following example grants all system privileges to user PAT. Then, revokes the ADMIN and DROP ANY TABLE privileges to disallow Pat the ability to perform all administration tasks or to drop any tables.
GRANT ALL PRIVILEGES TO PAT; REVOKE ADMIN, DROP ANY TABLE FROM PAT;
You may also REVOKE ALL PRIVILEGES that were granted to a user. This removes all system privileges from the user, except what the user inherits from the PUBLIC role, as demonstrated below for user PAT:
REVOKE ALL PRIVILEGES FROM PAT;
TimesTen databases are accessed through Data Source Names (DSNs). If a user tries to use a DSN that has connection attributes for which they do not have privileges, such as first connection attributes, they receive an error.
For a complete description of first connection attributes, see "Connection Attributes" in the Oracle TimesTen In-Memory Database Reference.
All users must be granted the CREATE SESSION system privilege by a user with the ADMIN privilege in order to connect to the database. The CREATE SESSION system privilege provides the authorization to connect to the database. The following example grants the CREATE SESSION privilege to Pat:
GRANT CREATE SESSION TO PAT;
A user with the ADMIN privilege can grant CREATE SESSION privilege to all users by granting this privilege to the PUBLIC role. This allows all users to connect to the database.
GRANT CREATE SESSION TO PUBLIC;
In addition to the ADMIN privilege, there are a few system privileges that confer a superset of abilities. The following provides a brief description of these privileges:
XLA: XLA readers can have global impact on the system. They create extra log volume, and can cause long log holds if they do not advance their bookmarks. You must have the XLA system privilege to connect as an XLA reader.
CACHE_MANAGER: The CACHE_MANAGER privilege is used for cache group administrator operations. See "Granting or revoking privileges for cache groups" for details.
When you want to grant or revoke privileges for a user, you can grant or revoke privileges for a single object or for that type of object anywhere in the database.
|
Note: To grant or revoke privileges for a single object, use object privileges, which are described in "Granting or revoking object privileges". |
The system privileges that contain the ANY keyword enable the user to perform the functions on all objects of the same type in the database. These system privileges are CREATE ANY object_type, DROP ANY object_type, ALTER ANY object_type, SELECT ANY object_type, UPDATE ANY TABLE, INSERT ANY TABLE, DELETE ANY TABLE, and EXECUTE ANY PROCEDURE.
|
Note: For a full description of these privileges, see "Privileges" in the Oracle TimesTen In-Memory Database SQL Reference. For details on the cache group system privileges that contain theANY keyword, see "Granting or revoking privileges for cache groups". |
The following sections provide more details for the CREATE ANY object_type, DROP ANY object_type, and ALTER ANY object_type system privileges:
Dropping a table, view, materialized view, sequence, procedure, function, package or synonym
Altering a table, view, materialized view, sequence, procedure, function or package
To create a table, view, materialized view, sequence, PL/SQL procedure, PL/SQL function, PL/SQL package, or synonym within the user's namespace or another user's namespace, you must have the appropriate CREATE object_type or CREATE ANY object_type system privileges.
The following describes the CREATE and CREATE ANY system privileges:
The CREATE object_type privilege grants a user the ability to create that object, but only in the user's own schema. After creation, the user owns this object and thus, automatically has been granted all privileges for that object.
Other privileges are required if a user wants to create cache groups.
The CREATE ANY object_type privilege grants a user the ability to create any object of that type in the database, even in another user's schema. The object types include table, index, view, materialized view, sequence, synonym and procedure. The CREATE ANY object_type privileges are CREATE ANY TABLE, CREATE ANY INDEX, CREATE ANY VIEW, CREATE ANY MATERIALIZED VIEW, CREATE ANY SEQUENCE, CREATE ANY SYNONYM and CREATE ANY PROCEDURE.
The following example grants the privilege to create any table in other users' schemas to user TERRY:
GRANT CREATE ANY TABLE TO TERRY;
The following example grants the privilege to create a table within the user's own schema:
GRANT CREATE TABLE TO TERRY;
Grant the DROP ANY object_type system privilege in order for a user to drop an object of object_type that the user does not own. For example, granting Pat this privilege enables Pat to drop the employees table that is owned by the user HR. A user always has the right to drop a table they own. The DROP ANY object_type privilege enables a user to drop any object of the specified type in the database, except for cache groups that require other privileges.
ALTER ANY PROCEDURE allows users to alter any procedure, function or package in the database. The ALTER ANY object_type privilege is necessary to modify the properties of objects that the user does not own. For example, if a procedure is created in the HR schema named Proc1 and if Pat is granted the ALTER ANY PROCEDURE privilege, Pat can successfully alter the procedure HR.Proc1.
To grant or revoke an object privilege, use the GRANT or REVOKE statements. The syntax for the object-level GRANT or REVOKE statement requires the name of the object on which the grant or revoke is applied. The syntax for the GRANT and REVOKE statements is described in the "SQL Statements" chapter in the Oracle TimesTen In-Memory Database SQL Reference.
The following sections describe and provide examples on the object privileges for all object types, except for the cache admin objects. The cache object privileges are described in "Granting or revoking privileges for cache groups".:
|
Note:
|
Object Privileges needed when creating foreign key with REFERENCES clause
Object privileges for PL/SQL functions, procedures and packages
You can grant all privileges for an object to a user with the ALL keyword. This essentially grants a user the right to perform any operation on the object.
There are no specific object privileges for DROP or ALTER. These operations cannot be granted for individual objects; instead, granting the appropriate system privilege enables a user other the owner of an object to DROP or ALTER that object.
For example, GRANT ALL ON employees TO PAT grants all privileges for the employees table to user PAT. It is possible to revoke individual privileges after granting all object privileges. For instance, the following is a valid sequence of operations:
GRANT ALL ON HR.employees TO PAT; REVOKE DELETE ON HR.employees FROM PAT;
You may also REVOKE ALL object privileges that were granted to a user for the object. This removes all privileges for the object from the user, as demonstrated below for user PAT:
REVOKE ALL ON HR.employees FROM PAT;
Both the object owner and a user with the ADMIN privilege can perform the GRANT ALL and REVOKE ALL statements.
For a user to perform operations on tables that they do not own, they must be granted the appropriate object privilege for that table. This includes privileges for tables within cache groups. The object privileges for tables include SELECT, UPDATE, DELETE, INSERT, INDEX and REFERENCES.
The following object privileges may be appropriate not only for authorization, but also for performance reasons:
The INDEX privilege enables the user to create an index on the table. Creating an index consumes additional space and impacts the performance of DML on the table. A specific grant for INDEX is required for a user to create an index.
The REFERENCES privilege enables the user to create a foreign key dependency on the table. Foreign key dependencies impact the performance of DML operations on the parent. For more details on the REFERENCES privilege, see "Object Privileges needed when creating foreign key with REFERENCES clause".
The following example grants the SELECT object privilege for the employees table in the HR schema to the user PAT:
GRANT SELECT ON HR.employees TO PAT;
The next example shows an example of how to grant the UPDATE privilege on the employees table owned by the user HR to the user PAT:
GRANT UPDATE ON HR.employees TO PAT;
For a user to create a view, that user must be granted the CREATE VIEW or CREATE ANY VIEW privilege. For a user to select from a view that they do not own, they need to be granted the SELECT object privilege for that view. Furthermore, the view itself needs to be valid; that is, the owner of the view must be granted the SELECT object privilege for all of the objects referenced by the view.
When user PAT creates a view owned by Pat and that view only references objects owned by Pat, then Pat is only required to be granted the CREATE VIEW privilege for this operation. If Pat creates a view owned by Terry that references objects owned by Terry, Pat is required to be granted the CREATE ANY VIEW privilege for this operation. For example:
CREATE VIEW PAT.VIEW1 as select * from PAT.TABLE1;
In this example, if Pat executes this statement, Pat only needs to be granted the CREATE VIEW privilege.
If user Pat creates a view, and the view references a table owned by Terry, then Pat needs to be granted the CREATE VIEW privilege and the SELECT object privilege on all of the objects referenced by the view. The owner of the view, not the view creator, must be granted the SELECT object privilege on the objects referenced by the view. Therefore, in this example, Pat must be granted the SELECT object privilege on TABLE2 that is owned by Terry. Once these privileges are granted, Pat can execute the following:
CREATE VIEW PAT.VIEW2 as select * from TERRY.TABLE2;
However, if a third user, Joe, executes this statement, then Joe must be granted the CREATE ANY VIEW privilege to create the view. Even though Joe is executing the statement, Pat, as the owner of the view, is still required to be granted the SELECT object privilege in order to perform the select on Terry's table.
TimesTen validates all views referenced at execution time. TimesTen will notify which privileges are not in place in order to perform the given operation.
For example:
CREATE VIEW PAT.VIEW2 as select * from TERRY.TABLE2; CREATE VIEW JOE.VIEW4 as select * from PAT.VIEW2, TERRY.TABLE4;
If Pat is executing these statements, the following privileges must be granted:
CREATE ANY VIEW privilege so that Pat can create the view in Pat's own schema as well as a view in Joe's schema.
User Joe must be granted the SELECT object privilege on Terry.Table4.
User Joe must be granted the SELECT object privilege on Pat.View2
User Pat must be granted the SELECT object privilege on Terry.Table2
When validating all references, TimesTen also validates that PAT.VIEW2 is still valid by verifying that Pat has the SELECT object privilege on TERRY.TABLE2. When you select from a view, TimesTen validates that the view itself is still valid, as well as any views referenced by that view.
For a user to perform operations on sequences that they do not own, they must be granted the SELECT object privilege. The SELECT privilege on a sequence allows the user to perform all operations on a sequence, including NEXTVAL, even though it ultimately updates the sequence.
For example, to grant SELECT privilege on the employees_seq sequence in the HR schema to the user PAT, issue the following statement:
GRANT SELECT ON HR.employees_seq TO PAT;
Pat can subsequently generate the next value of the sequence with the following statement:
SELECT HR.employees_seq.NEXTVAL FROM DUAL; < 207 > 1 row found.
In order to create a materialized view, a user needs the CREATE MATERIALIZED VIEW privilege. If the user is creating a materialized view in some other user's schema, the user needs the CREATE ANY MATERIALIZED VIEW privilege.
The owner of the materialized view needs to have CREATE TABLE privilege as well as SELECT privileges on every detail table in that materialized view. However, the owner of the materialized view is automatically granted the SELECT privilege on the detail tables if previously granted a higher-level system privilege, such as SELECT ANY TABLE or ADMIN.
For a user to select from a materialized view that they do not own, the user needs to be granted the object privileges for materialized views, which include SELECT, INDEX and REFERENCES. For more details on the privileges required, see the appropriate SQL statements in the Oracle TimesTen In-Memory Database SQL Reference.
In order for the materialized view to be valid, the owner of the view must be granted and must keep the SELECT object privilege for all of the detail tables referenced by the materialized view. If the owner of an existing materialized view loses the SELECT privilege on any detail table on which the materialized view is based, the materialized view becomes invalid.
The status of the materialized view is provided in the STATUS column of the SYS.DBA_OBJECTS, SYS.ALL_OBJECTS, and SYS.USER_OBJECTS views. The owner of the materialized view can see the status of its materialized views in the USER_OBJECTS view. Alternatively, execute the ttIsql describe command, which appends INVALID to the materialized view when it becomes invalid.
|
Note: If the owner of the materialized view was granted with a higher-level system privilege, such asSELECT ANY TABLE or ADMIN, the owner loses the required SELECT privileges on the detail tables if the higher-level system privilege is revoked. At this point, the materialized view becomes invalid. |
Users may still select from an invalid asynchronous materialized view without error. However, users will receive an error when selecting from an invalid synchronous materialized view.
Users that have the privilege to do so can still update the detail tables of the materialized view. However, the invalid materialized view will not reflect these changes. In addition, for asynchronous materialized views, the materialized view log will not be updated if no valid materialized views depend on them.
REFRESH on an invalid synchronous materialized view fails with an error.
If the owner of the materialized view has been re-granted the privilege that was previously revoked, a REFRESH on an invalid COMPLETE asynchronous materialized view succeeds and the asynchronous materialized view is now valid.
In order to fix an invalid materialized view, you must grant the appropriate privileges to the owner of the materialized view and then drop and re-c Yߦreate the materialized view.
The REFERENCES clause in the CREATE or ALTER TABLE statements creates a foreign key dependency from the new child table column (TABLE1.COL1) on the parent table column (TABLE2.PK) as shown in the following operation:
ALTER TABLE PAT.TABLE1 ADD CONSTRAINT FK1
FOREIGN KEY (COL1) REFERENCES PAT.TABLE2 (PK);
In this example, the user executing the SQL must have ALTER ANY TABLE privilege. Since Pat owns both tables, no additional privileges are needed since Pat owns both tables.
However, if the REFERENCES clause refers to a table not owned by this user, then the REFERENCES object privilege on the table not owned by the user is required before execution is allowed. For example:
ALTER TABLE PAT.TABLE1 ADD CONSTRAINT FK1
FOREIGN KEY (COL1) REFERENCES TERRY.TABLE2 (PK);
In this example, the user executing this SQL must have ALTER ANY TABLE privilege. As in the previous example, if the user executing this SQL is Pat, the ALTER ANY TABLE privilege is not required because a table's owner can always modify its own table. In addition, the user Pat must be granted the REFERENCES privilege on TERRY.TABLE2 in order for Pat to create a foreign key involving a table owned by Terry.
A user who creates or alters a child table needs the REFERENCES object privilege on the parent table to create a foreign key dependency. The REFERENCES privilege implicitly grants SELECT privileges for a user creating a foreign key on the parent table. However, this implicit grant does not mean that the user has the SELECT privilege on the parent table, so any SELECT statements will fail if the only privilege on the parent table is the REFERENCES privilege.
For a user to perform operations on PL/SQL functions, PL/SQL procedures or PL/SQL packages that they do not own, they must be granted the EXECUTE object privilege. When you grant a user EXECUTE privilege on a package, this automatically grants EXECUTE privilege on its component procedures and functions.
This privilege grants the right to the following:
Execute the procedure or function.
Access any program object declared in the specification of a package.
Compile the object implicitly during a call to a currently invalid or uncompiled function or procedure.
The EXECUTE privilege does not allow the user to create, drop or alter any procedure, function or package. This requires appropriate system privileges. For example, to explicitly compile using ALTER PROCEDURE or ALTER FUNCTION, the user must be granted the ALTER ANY PROCEDURE system privilege. For details on the system privileges for functions, procedures or packages, see "Enabling users to perform operations on any database object type".
For a user to create or drop private or public synonyms, the user must have the following privileges:
Table 4-1 Privileges for synonyms
| Action | Required privilege |
|---|---|
|
Create a private synonym in the user's own schema. |
|
|
Create a private synonym in another user's schema. |
|
|
Create a public synonym. |
|
|
Drop a private synonym in the user's own schema. |
No privilege needed. |
|
Drop a private synonym in another user's schema. |
|
|
Drop a public synonym. |
|
In addition, in order to use a synonym, the user must have the appropriate access privileges for the object that the synonym refers to. For example, if you create a synonym for a view, then to select from that view using the synonym, the user would need the SELECT privilege that is necessary to select from a view.
You can grant multiple object privileges in the same GRANT or REVOKE statement for the same database object for one or more users. For example, the following grants Terry the SELECT and UPDATE object privileges on the HR.employees table in the same SQL statement.
GRANT SELECT, UPDATE ON HR.employees TO TERRY;
You can also grant multiple system privileges to one or more users with the same GRANT or REVOKE statement. The following example grants multiple system privileges to both Terry and Pat.
GRANT CREATE ANY TABLE, CREATE SESSION TO TERRY, PAT;
You cannot combine system and object privileges in the same GRANT or REVOKE statement.
In order for a user to be able to perform activities involving any cache group, the user must have the appropriate cache group privileges. There are system and object privileges for cache groups, where system privileges confer abilities beyond a singular object.
|
Note: Passthrough does not require any privileges to be granted, since the privilege checking will be performed by the Oracle Database with the user credentials. For details on passthrough, see the Oracle In-Memory Database Cache User's Guide. |
The following sections provide an overview of cache group privileges:
For a full list of all system and object privileges for cache group operations, see "Privileges" in the Oracle TimesTen In-Memory Database SQL Reference.
The cache group system privileges provide a user the ability to affect cache group objects across the database. The CACHE_MANAGER system privilege is the administrator privilege for cache groups. If a user has been granted the CACHE_MANAGER privilege, this user may perform any cache group operation. This privilege confers all cache group operation privileges, which are listed in the "Privilege hierarchy" section in the Oracle TimesTen In-Memory Database SQL Reference.
You must have the CACHE_MANAGER privilege to perform the initial load of a read-only cache group or to change the state of autorefresh on a read-only cache group. The initial load implicitly alters the state of the cache group autorefresh from paused to on.
The following grants the CACHE_MANAGER privilege to Pat:
GRANT CACHE_MANAGER TO PAT;
The privileges that the TimesTen users require depend on the types of cache group operations that you want to perform.
To create a cache group, a user must be granted either the CREATE CACHE GROUP or CREATE ANY CACHE GROUP system privilege. In addition, the user must be granted either the CREATE ANY TABLE or CREATE TABLE privilege to create any underlying cache tables, depending on if the table is owned by the user or not.
To drop or alter a cache group that is not owned by the user, the user must be granted the DROP ANY CACHE GROUP or ALTER ANY CACHE GROUP privilege as appropriate. In addition, the user must be granted the DROP ANY TABLE privilege to drop any underlying cache tables, if the tables are not owned by the user.
|
Note: All cache group privileges are described in detail in the "Setting Up a Caching Infrastructure" chapter in the Oracle In-Memory Database Cache User's Guide. |
For example, the following confers the privilege for a user to alter any cache group in the database:
GRANT ALTER ANY CACHE GROUP TO PAT;
|
Note: Users with certain privileges must also be created on the Oracle database to own Oracle tables and to store cache grid information. The privileges required for the Oracle cache administration user and the TimesTen cache manager user for each cache operation are listed in the "Setting Up a Caching Infrastructure" chapter in the Oracle In-Memory Database Cache User's Guide. |
Other system privileges for cache group operations are for performing the following on objects not owned by the user:
FLUSH ANY CACHE GROUP: Enables users to flush any cache group in the database.
LOAD ANY CACHE GROUP: Enables users to load any cache group in the database.
UNLOAD ANY CACHE GROUP: Enables users to unload any cache group in the database.
REFRESH ANY CACHE GROUP: Enables users to refresh any cache group in the database.
The object privileges for cache group operations are granted to a user for performing the operation on a single, defined object. The following are the object privileges for cache group objects:
FLUSH: Enables the user to flush a cache group owned by another user.
LOAD: Enables the user to load a cache group owned by another user.
UNLOAD: Enables the user to unload a cache group owned by another user.
REFRESH: Enables the user to refresh a cache group owned by another user.
For example, the following example grants Pat the cache group object privilege to perform a FLUSH on the cache group CACHEGRP that is owned by Terry:
GRANT FLUSH ON TERRY.CACHEGRP TO PAT;
For details on cache group operations, see the Oracle In-Memory Database Cache User's Guide.
You can view the privileges granted to each user through the following views:
Table 4-2 System privilege views
| View name | Description |
|---|---|
|
Returns all of the system privileges granted to the current user. | |
|
Returns the list of system privileges granted to all users and inherited from the | |
|
Returns all of the object privileges granted to the current user. | |
|
Returns the results of both | |
|
Returns the object privileges granted to all users and inherited from the |
For example, perform the following to see all of the system privileges granted to all users:
Command> SELECT * FROM SYS.DBA_SYS_PRIVS; < SYS, ADMIN, YES > < SYSTEM, ADMIN, YES > < TERRY, ADMIN, YES > < TERRY, CREATE ANY TABLE, NO > < PAT, CACHE_MANAGER, NO > 5 rows found.
|
Note: For details on these views, see "System Tables" in the Oracle TimesTen In-Memory Database System Tables and Views Reference. |
Many of the utilities and built-in procedures require a certain privilege in order to execute. In addition, in order to modify or connect with certain first connection attributes, certain privileges are required. First connection attributes are set when a database is first loaded, and only the instance administrator can load a database with first connection attribute settings. The required privilege for each is described with the utility, built-in procedure or first connection attribute description in the Oracle TimesTen In-Memory Database Reference.
If you have tables related by foreign key constraints, then the following applies:
If ON DELETE CASCADE is specified on a foreign-key constraint for a child table, a user can delete rows from the parent table resulting in deletions from the child table without requiring an explicit DELETE privilege on the child table. However, a user must have the DELETE privilege on the parent table for this to occur automatically.
When you perform an insert or update on a child table, TimesTen determines if there is a foreign key constraint violation on the parent table resulting from the change to the child table. In this case, a user is required to have the INSERT or UPDATE privilege on the child table, but not a SELECT privilege on the parent table.
A user who creates a child table needs the REFERENCES object privilege on the parent table to create a foreign key dependency. See "Object Privileges needed when creating foreign key with REFERENCES clause" for more details.
Operations Guide
11g Release 2 (11.2.2)
E21633-05
September 2012
Oracle TimesTen In-Memory Database Operations Guide, 11g Release 2 (11.2.2)
E21633-05
Copyright © 1996, 2012, Oracle and/or its affiliates. All rights reserved.
This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:
U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.
This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.
The TimesTen cost-based query optimizer uses information about an application's tables and their available indexes to choose a fast path to the data. Application developers can examine the plan chosen by the optimizer to check that indexes are used appropriately. If necessary, application developers can also modify the optimizer's behavior so that it chooses a different plan.
This chapter includes the following topics:
It is useful to understand when TimesTen performs query optimization, since a single command may be optimized several times.
TimesTen invokes the optimizer whenever a SELECT, UPDATE, DELETE, INSERT SELECT or CREATE MATERIALIZED VIEW statement is prepared through an ODBC SQLPrepare or SQLExecDirect function or any of the JDBC execute methods. The resulting plan persists until an invalidating event occurs, or the command is dropped by the application.
A command is invalidated under the following circumstances:
A table it uses is dropped
A table it uses is altered
An index on a table it references is dropped
An index is created on a table it references
Statistics are recomputed with the invalidation option set to 1 in either the ttIsql statsupdate command, the ttOptUpdateStats built-in procedure, or the ttOptEstimateStats built-in procedures.
|
Note: For complete details on when to calculate statistics, see "Compute exact or estimated statistics". In addition, see "ttIsql," "ttOptUpdateStats," or "ttOptEstimateStats" in the Oracle TimesTen In-Memory Database Reference. |
An invalid command is usually reprepared automatically just before it is re-executed. This means that the optimizer is invoked again at this time, possibly resulting in a new plan. Thus, a single command may be prepared several times.
|
Note: When using JDBC, you must manually reprepare commands when a table has been altered. |
A command may have to be prepared manually if, for example, the table that the command referenced was dropped and a new table with the same name was created. When you prepare a statement manually, you should commit the prepare statement so it can be shared. If the command is recompiled because it was invalid, and if recompilation involves DDL on one of the referenced tables, then the prepared statement must be committed to release the command lock.
For example, in ODBC a command joining tables T1 and T2 may undergo the following changes:
| Action | Description |
|---|---|
SQLPrepare | Command is prepared. |
SQLExecute | Command is executed. |
SQLExecute | Command is re-executed. |
| Create Index on T1 | Command is invalidated. |
SQLExecute | Command is reprepared, then executed. |
SQLExecute | Command is re-executed. |
ttOptUpdateStats on T1 | Command is invalidated if the invalidate flag is passed to the ttOptUpdateStats procedure. |
SQLExecute | Command is reprepared, then executed. |
SQLExecute | Command is re-executed. |
SQLFreeStmt | Command is dropped. |
In JDBC, a command joining tables T1 and T2 may undergo the following changes:
| Action | Description |
|---|---|
Connection.prepareStatement | Command is prepared. |
PreparedStatement.execute | Command is executed. |
PreparedStatement.execute | Command is re-executed. |
| Create Index on T1 | Command is invalidated. |
PreparedStatement.execute | Command is reprepared, then executed. |
PreparedStatement.execute | Command is re-executed. |
ttOptUpdateStats on T1 | Command is invalidated if the invalidate flag is passed to the ttOptUpdateStats procedure. |
PreparedStatement.execute | Command is reprepared, then executed. |
PreparedStatement.execute | Command is re-executed. |
PreparedStatement.close | Command is dropped. |
As illustrated, optimization is generally performed at prepare time, but it may also be performed later when indexes are dropped or created, or when statistics are modified. Optimization does not occur if a prepare can use a command in the cache.
If a command was prepared with the genPlan flag set, it will be recompiled with the same flag set. Thus, the plan is generated even though the plan for another query was found in the SYS.PLAN table.
If an application specifies hints to modify the optimizer's behavior, these hints persist until the command is deleted. See "Modifying plan generation" for more information. For example, when the ODBC SQLPrepare function or JDBC Connection.prepareStatement method is called again on the same handle or when the SQLFreeStmt function or PreparedStatement.close method is called. This means that any intermediate reprepare operations that occur because of invalidations will use those same hints.
All commands executed—SQL statements, built-in procedures, and so on—are stored in the SQL Command Cache, which uses temporary memory. The commands are stored up until the limit of the SQL Command Cache is reached, then the new commands are stored after the last used commands are removed. You can retrieve one or more of these commands that are stored in the SQL Command Cache.
|
Note: This section describes viewing the commands stored in the SQL Command Cache. For details on how to view the query plans associated with these commands, see "Viewing query plans associated with commands stored in the SQL Command Cache". |
The following sections describe how to view commands cached in the SQL Command Cache:
You can view all one or more commands or details of their query plans with the ttSqlCmdCacheInfo and ttSqlCmdQueryPlan built-in procedures. Use the query plan information to monitor and troubleshoot your queries.
Viewing commands and query plans can help you perform the following:
Detect updates or deletes that are not using an index scan.
Monitor query plans of executing queries to ensure all plans are optimized.
Detect applications that do not prepare SQL statements or that re-prepare the same statement multiple times.
Discover the percentage of space used in the command cache for performance evaluation.
The commands executed against the TimesTen database are cached in the SQL command cache. The ttSqlCmdCacheInfo built-in procedure displays a specific or all cached commands in the TimesTen SQL command cache. By default, all commands are displayed; if you specify a command id, then only this command is retrieved for display.
The command data is saved in the following format:
Command identifier, which is used to retrieve a specific command or its associated query plan.
Private connection identifier.
Counter for the number of executions.
Counter for the number of times the user prepares this statement.
Counter for the number of times the user re-prepares this SQL statement.
Freeable status, where if the value is one, then the subdaemon can free the space with the garbage collector. A value of zero determines that the space is not able to be freed.
Total size in bytes allocated for this command in the cache.
User who created the command.
Query text up to 1024 characters.
At the end of the list of all commands, a status is printed of how many commands were in the cache.
The following examples show how to display all or a single command from the SQL Command Cache using the ttSqlCmdCacheInfo built-in utility:
Example 10-1 Displaying all commands in the SQL Command Cache
This example executes within ttIsql the ttSqlCmdCacheInfo built-in procedure without arguments to show all cached commands. The commands are displayed in terse format. To display the information where each column is prepended with the column name, execute vertical on before executing the ttsqlCmdCacheInfo procedure.
Command> call ttsqlCmdCacheInfo;
< 528079360, 2048, 0, 1, 0, 1, 2168, PAT , select * from
t7 where x7 is not null or exists (select 1 from t2,t3 where not 'tuf' like
'abc') >
< 527609108, 2048, 0, 1, 0, 1, 2960, PAT , select * from
t1 where x1 = (select x2 from t2 where z2 in (1,3) and y1=y2) order by 1, 2, 3 >
< 528054656, 2048, 0, 1, 0, 1, 1216, PAT , create table
t2(x2 int,y2 int, z2 int) >
< 528066648, 2048, 0, 1, 0, 1, 1176, PAT , insert into t2
select * from t1 >
< 528013192, 2048, 0, 1, 0, 1, 1848, PAT , select * from
t1 where exists (select * from t2 where x1=x2) or y1=1 >
< 527582620, 2048, 0, 1, 0, 1, 1240, PAT , insert into t2
select * from t1 >
< 527614292, 2048, 0, 1, 0, 1, 2248, PAT , select * from
t1 where exists (select x2 from t2 where x1=x2) order by 1, 2, 3 >
< 528061248, 2048, 0, 1, 0, 1, 696, PAT , create index i1
on t3(y3) >
< 528070368, 2048, 0, 1, 0, 1, 824, PAT , call
ttOptSetOrder('t3 t4 t2 t1') >
< 528018856, 2048, 0, 1, 0, 1, 984, PAT , insert into t2
select * from t1 >
< 527606460, 2048, 0, 1, 0, 1, 2624, PAT , select * from
t1 where x1 = (select x2 from t2 where y1=y2) order by 1, 2, 3 >
< 528123000, 2048, 0, 1, 0, 1, 3616, PAT , select * from
t1 where x1 = 1 or x1 = (select x2 from t2,t3 where z2=t3.x3) >
< 528074624, 2048, 0, 1, 0, 1, 856, PAT , call
ttOptSetOrder('t4 t2 t3 t1') >
< 527973892, 2048, 0, 1, 0, 1, 2872, PAT , select * from
t1 where x1 in (select x2 from t2) or x1 in (select x3 from t3) order by 1, 2, 3 >
< 527953876, 2048, 0, 1, 0, 1, 3000, PAT , select * from
t1 where x1 = (select x2 from t2) order by 1, 2, 3 >
< 527603900, 2048, 0, 1, 0, 1, 2440, PAT , select * from
t1 where x1 in (select x2 from t2 where y1=y2) order by 1, 2, 3 >
< 528093308, 2048, 0, 1, 0, 1, 3608, PAT , select * from
t1 where x1 = 1 or x1 = (select x2 from t2,t3 where z2=t3.x3 and t3.z3=1) >
< 528060608, 2048, 0, 1, 0, 1, 696, PAT , create index i1
on t2 (y2) >
Example 10-2 Displaying a single SQL command
If you provide a command id as the input for the ttSqlCmdCacheInfo, the single command is displayed from within the SQL Command Cache. You can discover the command id from executing this built-in procedure without input. The command id is the first column displayed.
The following example displays the command identified by Command ID of 527973892. It is displayed in terse format; to view with the column headings prepended, execute vertical on before executing the ttSqlCmdCacheInfo built-in.
Command> call ttsqlCmdCacheInfo(527973892); < 527973892, 2048, 0, 1, 0, 1, 2872, PAT , select * from t1 where x1 in (select x2 from t2) or x1 in (select x3 from t3) order by 1, 2, 3 > 1 row found.
You can view the query plan for a command in one of two ways: storing the latest query plan into the system PLAN table or viewing all cached commands and their query plans in the SQL command cache. Both methods are described in the following sections:
The optimizer prepares the query plans. For the last SQL statement to be executed—such as a prepared SELECT, UPDATE, DELETE, INSERT SELECT, CREATE TABLE, CREATE MATERIALIZED VIEW and so on—you can instruct that the plan be stored in the system PLAN table:
Instruct TimesTen to generate the plan and store it in the system PLAN table.
Prepare the statement means calling the ODBC SQLPrepare function or JDBC Connection.prepareStatement method on the statement. TimesTen stores the plan into the PLAN table.
Read the generated plan within the SYS.PLAN table.
The stored plan is updated automatically whenever the command is reprepared. Re-preparation occurs automatically if one or more of the following occurs:
A table in the statement is altered.
If indexes are created or dropped.
The application invalidates commands when statistics are updated with the invalidate option in the ttOptUpdateStats built-in procedure.
|
Note: For more information, seettOptUpdateStats in the Oracle TimesTen In-Memory Database Reference. |
For these cases, read the PLAN table to view how the plan has been modified.
Before you can view the plan in the system PLAN table, call the built-in ttOptSetFlag procedure with the GenPlan flag. This call informs TimesTen that all subsequent calls to the ODBC SQLPrepare function or JDBC Connection.prepareStatement method in the transaction should store the resulting plan in the current SYS.PLAN table.
|
Note: Make sureAUTOCOMMIT is not set. If it is, the current transaction completes after the processing of the command and prepares in the next transaction are not affected. |
The SYS.PLAN table only stores one plan, so each call to the ODBC SQLPrepare function or JDBC Connection.prepareStatement method overwrites any plan currently stored in the table.
If a command is prepared with the genPlan flag set, it is recompiled with this flag. Thus, the plan is generated even though the plan for another query was found in the SYS.PLAN table.
For example, try the query and optimizer hints with the ttIsql utility. To display optimizer plans, issue the following commands:
autocommit 0; showplan 1;
Once plan generation has been turned on and a command has been prepared, one or more rows in the SYS.PLAN table store the plan for the command. The number of rows in the table depends on the complexity of the command. Each row has seven columns, as described in "System Tables" in the Oracle TimesTen In-Memory Database System Tables and Views Reference.
Example 10-3 Generating a query plan
This example uses the following query:
SELECT COUNT(*) FROM T1, T2, T3 WHERE T3.B/T1.B > 1 AND T2.B <> 0 AND T1.A = -T2.A AND T2.A = T3.A
The optimizer generates the five SYS.PLAN rows shown in the following table. Each row is one step in the plan and reflects an operation that is performed during query execution.
| Step | Level | Operation | TblNames | IXName | Pred | Other Pred |
|---|---|---|---|---|---|---|
| 1 | 3 | TblLkRangeScan | T1 | IX1 | ||
| 2 | 3 | TblLkRangeScan | T2 | IX2(D) | T2.B <> 0 | |
| 3 | 2 | MergeJoin | T1.A = -T2.A | |||
| 4 | 2 | TblLkRangeScan | T3 | IX3(D) | ||
| 5 | 1 | MergeJoin | T2.A = T3.A | T3.B / T1.B > 1 |
For details about each column in the SYS.PLAN table, see "Describing the PLAN table columns".
The SYS.PLAN table has seven columns.
Indicates the order of operation, which always starts with one. Example 10-3 uses a table lock range scan in the following order:
Table locking range scan of IX1 on table T1.
Table locking range scan of IX2 on T2.
Merge join of T1 and T2 and so forth.
Indicates the position of the operation in the join-tree diagram that describes the execution. For Example 10-3, the join tree is as follows:
Indicates the type of operation being executed. For a description of the potential values in this field and the type of table scan each represents, see SYS.PLAN in "System Tables" in the Oracle TimesTen In-Memory Database System Tables and Views Reference.
Not all operations the optimizer performs are visible to the user. Only operations significant to performance analysis are shown in the SYS.PLAN table. TblLk is an optimizer hint that is honored at execution time in Serializable or Read Committed isolation. Table locks are used during a scan only if row locks are disabled during preparation.
Indicates the table that is being scanned. This column is used only when the operation is a scan. In all other cases, this column is NULL.
Indicates the index that is being used. This column is used only when the operation is an index scan using an existing index—such as a hash or range scan. In all other cases, this column is NULL. Names of range indexes are followed with "(D)" if the scan is descending—from large to small rather than from small to large.
Indicates the predicate that participates in the operation, if there is one. Predicates are used only with index scan and MergeJoin operations. The predicate character string is limited to 1,024 characters.
This column may be NULL—indicating no predicate—for a range scan. The optimizer may choose a range scan over a table scan because, in addition to filtering, it has two useful properties:
Rows are returned in sorted order, on index key.
Rows may be returned faster, especially if the table is sparse.
In Example 10-3, the range scans are used for their sorting capability; none of them evaluates a predicate.
Indicates any other predicate that is applied while the operation is being executed. These predicates do not participate directly in the scan or join but are evaluated on each row returned by the scan or join.
For example, at step two of the plan generated for Example 10-3, a range scan is performed on table T2. When that scan is performed, the predicate T2.B <> 0 is also evaluated. Similarly, once the final merge-join has been performed, it is then possible to evaluate the predicate T3.B / T1.B > 1.
Use the query plan information to monitor and troubleshoot your queries.
|
Note: For more reasons why to use thettSqlCmdQueryPlan built-in procedure, see "Managing performance and troubleshooting commands". |
The ttSqlCmdQueryPlan built-in procedure displays the query plan of a specific statement or all statements in the command cache. It displays the detailed run-time query plans for the cached SQL queries. By default, all query plans are displayed; if you specify the command id taken from the command output, only the query plan for the specified command is displayed.
|
Note: If you want to display a query plan for a specific command, you must provide the command identifier, which is displayed with thettSqlCmdCacheInfo built-in procedure. See "Displaying commands stored in the SQL Command Cache" for full details. |
The plan data displayed when you invoke this built-in procedure is as follows:
Command identifier
Query text up to 1024 characters
Step number of the current operation in the run-time query plan
Level number of the current operation in the query plan tree
Operation name of current step
Name of table used
Owner of the table
Name of index used
If used and available, the index predicate
If used and available, the non-indexed predicate
|
Note: For more information on how to view this information, see "Reading query plan from the PLAN table". The source of the data may be different, but the mapping and understanding of the material is the same as the query plan in the systemPLAN table. |
The ttSqlCmdQueryPlan built-in process displays the query plan in a raw data format. Alternatively, you can execute the ttIsql explain command for a formatted version of this output. For more information, see "Display query plan for statement in SQL Command Cache".
The following examples show how to display all or a single SQL query plan from the SQL Command Cache using the ttSqlCmdQueryPlan built-in procedure:
Example 10-4 Displaying all SQL query plans
You can display all SQL query plans associated with commands stored in the command cache with the ttSqlCmdQuery plan built-in procedure within the ttIsql utility.
The following example shows the output when executing the ttSqlCmdQueryPlan built-in procedure without arguments, which displays detailed run-time query plans for all valid queries. For invalid queries, there is no query plan; instead, the query text is displayed.
The query plans are displayed in terse format. To view with the column headings prepended, execute vertical on before executing the ttSqlCmdQueryPlan built-in procedure.
Note: For complex expressions, there may be some difficulties in printing out the original expressions.
Command> call ttSqlCmdQueryPlan();
< 528079360, select * from t7 where x7 is not null or exists (select 1 from t2,t3
where not 'tuf' like 'abc'), <NULL>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL>,
<NULL>, <NULL> >
< 528079360, <NULL>, 0, 2, RowLkSerialScan , T7
, PAT , , , >
< 528079360, <NULL>, 1, 3, RowLkRangeScan , T2
, PAT , I2 , , NOT(LIKE( tuf
,abc ,NULL )) >
< 528079360, <NULL>, 2, 3, RowLkRangeScan , T3
, PAT , I2 , , >
< 528079360, <NULL>, 3, 2, NestedLoop ,
, , , , >
< 528079360, <NULL>, 4, 1, NestedLoop(Left OuterJoin) ,
, , , , >
< 528079360, <NULL>, 5, 0, Filter ,
, , , , X7 >
< 527576540, call ttSqlCmdQueryPlan(527973892), <NULL>, <NULL>, <NULL>, <NULL>,
<NULL>, <NULL>, <NULL>, <NULL> >
< 527576540, <NULL>, 0, 0, Procedure Call ,
, , , , >
< 528054656, create table t2(x2 int,y2 int, z2 int), <NULL>, <NULL>, <NULL>,
<NULL>, <NULL>, <NULL>, <NULL>, <NULL> >
< 528066648, insert into t2 select * from t1, <NULL>, <NULL>, <NULL>, <NULL>,
<NULL>, <NULL>, <NULL>, <NULL> >
< 528066648, <NULL>, 0, 0, Insert , T2
, PAT , , , >
< 528013192, select * from t1 where exists (select * from t2 where x1=x2) or
y1=1, <NULL>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL> >
< 528061248, create index i1 on t3(y3), <NULL>, <NULL>, <NULL>, <NULL>, <NULL>,
<NULL>, <NULL>, <NULL> >
< 528070368, call ttOptSetOrder('t3 t4 t2 t1'), <NULL>, <NULL>, <NULL>, <NULL>,
<NULL>, <NULL>, <NULL>, <NULL> >
< 528070368, <NULL>, 0, 0, Procedure Call ,
, , , , >
< 528018856, insert into t2 select * from t1, <NULL>, <NULL>, <NULL>, <NULL>,
<NULL>, <NULL>, <NULL>, <NULL> >
< 527573452, call ttsqlCmdCacheInfo(527973892), <NULL>, <NULL>, <NULL>, <NULL>,
<NULL>, <NULL>, <NULL>, <NULL> >
< 527573452, <NULL>, 0, 0, Procedure Call ,
, , , , >
< 528123000, select * from t1 where x1 = 1 or x1 = (select x2 from t2,t3 where
z2=t3.x3), <NULL>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL> >
< 528123000, <NULL>, 0, 2, RowLkSerialScan , T1
, PAT , , , >
< 528123000, <NULL>, 1, 6, RowLkRangeScan , T2
, PAT , I2 , , >
< 528123000, <NULL>, 2, 6, RowLkRangeScan , T3
, PAT , I2 , , Z2 = X3; >
< 528123000, <NULL>, 3, 5, NestedLoop ,
, , , , >
< 528123000, <NULL>, 4, 4, Materialized View ,
, , , , >
< 528123000, <NULL>, 5, 3, GroupBy ,
, , , , >
< 528123000, <NULL>, 6, 2, Filter ,
, , , , X1 =
colum_name; >
< 528123000, <NULL>, 7, 1, NestedLoop(Left OuterJoin) ,
, , , , >
< 528123000, <NULL>, 8, 0, Filter ,
, , , , X1 = 1; >
Example 10-5 Displaying a single SQL query plan
You can display any query plan associated with a command by providing the command id of the command as the input for the ttSqlCmdQueryPlan built-in procedure. The single query plan is displayed from within the SQL Command Cache. You can discover the command id from executing this ttSqlCmdCacheInfo built-in without input. The command id is the first column displayed.
The following example displays the query plan of the command identified by command id of 528078576. It is displayed in terse format; to view with the column headings prepended, execute vertical on before executing the ttSqlCmdQueryPlan built-in procedure.
Note: for complex expressions, there are some difficulties to print original expressions.
Command> call ttSqlCmdQueryPlan( 528078576); < 528078576, select * from t1 where 1=2 or (x1 in (select x2 from t2, t5 where y2 in (select y3 from t3)) and y1 in (select x4 from t4)), <NULL>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL> > < 528078576, <NULL>, 0, 4, RowLkSerialScan , T1 , PAT , , , > < 528078576, <NULL>, 1, 7, RowLkRangeScan , T2 , PAT , I2 , , > < 528078576, <NULL>, 2, 7, RowLkRangeScan , T5 , PAT , I2 , , > < 528078576, <NULL>, 3, 6, NestedLoop , , , , , > < 528078576, <NULL>, 4, 6, RowLkRangeScan , T3 , PAT , I1 , ( (Y3=Y2; ) ) , > < 528078576, <NULL>, 5, 5, NestedLoop , , , , , > < 528078576, <NULL>, 6, 4, Filter , , , , , X1 = X2; > < 528078576, <NULL>, 7, 3, NestedLoop(Left OuterJoin) , , , , , > < 528078576, <NULL>, 8, 2, Filter , , , , , > < 528078576, <NULL>, 9, 2, RowLkRangeScan , T4 , PAT , I2 , , Y1 = X4; > < 528078576, <NULL>, 10, 1, NestedLoop(Left OuterJoin) , , , , , > < 528078576, <NULL>, 11, 0, Filter , , , , , > 13 rows found. Command>
If you decide that you want to modify a query plan, you can only modify the query plan that exists in the system PLAN table as described in "Viewing a query plan from the system PLAN table". Once you do modify the query plan, it does not replace the query plan, but creates a new query plan with your changes.
The following sections describe why you may want to modify execution plans and then how to modify them:
Applications may want to modify an execution plan for two reasons:
The plan is optimally fast but is ill-suited for the application. The optimizer may select the fastest execution path, but this path may not be desirable from the application's point of view. For example, if the optimizer chooses to use certain indexes, these choices may prevent other operations-such as certain update or delete operations-from occurring simultaneously on the indexed tables. In this case, an application can prevent the use of those indexes.
The plan chosen by the optimizer may also consume more memory than is available or than the application wants to allocate. For example, this may happen if the plan stores intermediate results or requires the creation of temporary indexes.
The plan is not optimally performant. The query optimizer chooses the plan that it estimates will execute the fastest based on its knowledge of the tables' contents, available indexes, statistics, and the relative costs of various internal operations. The optimizer often has to make estimates or generalizations when evaluating this information, so there can be instances where it does not choose the fastest plan. In this case, an application can adjust the optimizer's behavior to try to produce a better plan.
Applications can modify an execution plan by providing hints to the optimizer. Hints are specified by calls to one of the TimesTen optimizer built-in procedures and are in effect for all calls to the ODBC SQLPrepare function or JDBC PreparedStatement objects in the transaction. For more information on how to provide these hints, see "How to modify execution plan generation".
|
Note: Make sureAUTOCOMMIT is not set. If it is, the current transaction completes after processing the ttOptSetFlag procedure and prepares in the next transaction are not affected. |
If a command is prepared with certain hints in effect, those hints continue to apply if the command is reprepared automatically, even when this happens outside the initial prepare transaction. This can happen when a table is altered, or an index is dropped or created, or when statistics are modified, as described in "When optimization occurs".
If a command is prepared without hints, subsequent hints will not affect the command if it is reprepared automatically. An application must call the ODBC SQLPrepare function or JDBC Connection.prepareStatement method a second time so that hints have an effect.
Example 10-6 Tuning a join when using ODBC
When using ODBC, a developer tuning a join on T1 and T2 might go through the steps shown in the following figure.
During execution, the application may then go through the steps shown in the following figure.
Example 10-7 Tuning a join when using JDBC
When using JDBC, a developer tuning a join on T1 and T2 might go through the steps shown in the following figure.
During execution, the application may then go through the steps shown in the following figure.
You can apply hints to change the query optimizer behavior, which modifies the execution plan generation.
To change the query optimizer behavior for a transaction, an application calls one of the following built-in procedures using the ODBC procedure call interface:
ttOptSetOrder—Enables an application to specify the table join order.
ttOptUseIndex—Enables an application to specify that an index be used or to disable the use of certain indexes.
ttOptClearStats, ttOptEstimateStats, ttOptSetColIntvlStats, ttOptSetTblStats, ttOptUpdateStats—Manipulate statistics that the TimesTen Data Manager maintains on the application's data that are used by the query optimizer to estimate costs of various operations.
Some of these built-in procedures require that the user have privileges to the objects on which the utility executes. For full details on these built-in procedures and any privileges required, see "Built-In Procedures" in the Oracle TimesTen In-Memory Database Reference.
The following examples provide an ODBC and JDBC method on how to use the ttOptSetFlag built-in procedure:
|
Note: You can also experiment with optimizer settings using thettIsql utility. The commands that start with try control the optimizer hints. To view your current optimizer hint settings, use the optprofile command. |
Example 10-8 Using ttOptSetFlag in JDBC
This JDBC example illustrates the use of ttOptSetFlag to prevent the optimizer from choosing a merge join.
import java.sql.*;
class Example
{
public void myMethod() {
CallableStatement cStmt;
PreparedStatement pStmt;
. . . . .
try {
. . . . . . .
// Prevent the optimizer from choosing Merge Join
cStmt = con.prepareCall("{
CALL ttOptSetFlag('MergeJoin', 0)}");
cStmt.execute();
// Next prepared query
pStmt=con.prepareStatement(
"SELECT * FROM Tbl1, Tbl2 WHERE Tbl1.ssn=Tbl2.ssn");
. . . . . . .
catch (SQLException ex) {
ex.printStackTrace();
}
}
. . . . . . .
}
Example 10-9 Using ttOptSetFlag in ODBC
This ODBC example illustrates the use of ttOptSetFlag to prevent the optimizer from choosing a merge join.
#include <sql.h>
SQLRETURN rc;
SQLHSTMT hstmt; fetchStmt;
....
rc = SQLExecDirect (hstmt, (SQLCHAR *)
"{CALL ttOptSetFlag (MergeJoin, 0)}",
SQL_NTS)
/* check return value */
...
rc = SQLPrepare (fetchStmt, ...)
/* check return value */
...
ACID transaction semantics
An acronym referring to the four fundamental properties of a transaction: atomicity, consistency, isolation and durability.
atomicity
A property of a transaction whereby either all or none of the operations of a transaction are applied to the database.
backup instance
A set of files containing backup information for a given database, residing at a given backup path. See also "backup path", "full backup" and "incremental backup".
backup point
The time at which a backup begins. See also "backup path", "full backup" and "incremental backup".
bitmap index
Indexes are used to speed up queries on a table. Bitmap indexes are useful when searching and retrieving data from columns with low cardinality. That is, these columns can have only a few unique possible values.
cache instance
A set of rows related through foreign keys. Each cache instance contains exactly one row from the root table of a cache group and zero or more rows from the other tables in the cache group.
client/server
An approach to application design and development in which application processing is divided between components running on an end user's machine, such as the client, and a network server. Generally, user interface elements are implemented in the client component, while the server controls database access.
concurrency
The ability to have multiple transactions access and manipulate the database at the same time.
connection attribute
A character string that defines a connection parameter to be used when connecting to an ODBC data source. Connection attributes have the form name=value, where name is the name of the parameter and value is the parameter value. See also connection string.
connection request
A message sent by an application through an ODBC driver to an ODBC data source to request a connection to that data source.
connection string
A character string that defines the connection parameters to be used when connecting to an ODBC data source. A connection string is expressed as one or more connection attributes separated by semicolons.
consistency
A property of transactions whereby each transaction transforms the database from one consistent state to another.
data source definition
A named collection of connection attributes that defines the connection parameters to be used when connecting to an ODBC data source. See also "data source name".
data source name
A logical name by which an end user or application refers to an ODBC data source definition. Sometimes incorrectly used to mean "data source definition". See also "data source definition", ODBC.INI file.
data source name, client
A data source name defined on a TimesTen client machine that refers to a Server DSN on a server machine.
data source name, server
A system data source name (system DSN) defined on a server machine. Server Data Source Names become available to all TimesTen clients on a network when the TimesTen Server is running.
data source name, system
A data source name that is accessible by all users of a particular machine.
data source name, user
A data source name that is accessible only by the user who created the data source name.
durability
A property of transactions whereby the effects of a committed transaction survive system failures.
environment variable
A name, value pair maintained by the operating system that can be used to pass configuration parameters to an application.
event
An activity or occurrence that can be tracked by a logging mechanism in an application, service or operating system. See also "logging", "protocol message logging" and "event viewer".
event viewer
On Windows, a utility program used to view the contents of the operating system event log.
full backup
A database backup procedure in which a complete copy of a database is created. Typically, the first backup of a database must be a full backup. See also "incremental backup".
hash index
Indexes are used to speed up queries on a table. Hash indexes are useful for finding rows with an exact match on one or more columns.
host
A computer. Typically used to refer to a computer on a network that provides services to other computers on the network.
host name
A character string name that uniquely identifies a particular computer on a network. Examples: athena, thames.mycompany.com. See also "host".
in-line column
A column whose values are physically stored together with the other column values of a row.
incremental backup
A database backup procedure in which an existing backup is augmented with all the transaction log records created since its last full or incremental backup. See also "backup instance" and "full backup".
IP address
A numeric address that uniquely identifies a computer on a network and consists of four numbers separated by dots. Abbreviation for Internet Protocol address. Example: 123.61.129.91.
isolation
A property of transactions whereby each transaction runs as if it were the only transaction in the system.
listener thread
A thread that runs on the TimesTen Server that receives and processes connection requests from TimesTen Clients.
logging
The process by which an application, service or operating system records specific events that occur during processing.
network address
A host name, or IP address that uniquely identifies a particular computer on a network. Examples: 123.61.129.91, athena, thams.mycompany.com.
ODBC Administrator
A utility program used on Windows to create, configure and delete data source definitions.
ODBC driver
A library that implements the function calls defined in the ODBC API and enables applications to interact with ODBC data sources.
ODBC Driver Manager
A library that acts as an intermediary between an ODBC application and one or more ODBC drivers.
ODBC initialization file (ODBC INI)
The ODBC.INI file contains a list of Data Sources and any properties for each. Each Data Source name must have a driver property defined. This enables the driver to be loaded when a connect call is made.
Open Database Connectivity (ODBC)
A database-independent application programming interface that enables applications to access data stored in heterogeneous relational and non-relational databases. Based on the Call-Level Interface (CLI) specification developed by X/Open's SQL Access Group and first popularized by Microsoft on the Windows platform.
Open database connectivity (ODBC), is a database access protocol that lets you connect to a database and then prepare and run SQL statements against the database. In conjunction with an ODBC driver, an application can access any data source including data stored in spreadsheets, like Excel. Because ODBC is a widely accepted standard API, applications can be written to comply to the ODBC standard. The ODBC driver performs all mappings between the ODBC standard and the particular database the application is accessing. Using a data source-specific driver, an ODBC compliant program can access any data source without any more development effort.
TimesTen provides the ODBC interface so that applications of any type that are ODBC compliant can access TimesTen using the ODBC driver provided by TimesTen.
out-of-line column
A column whose values are physically stored separately from the other column values of a row.
phantom
A row that appears during one read but not during another read within the same transaction, due to the actions of other concurrently executing transactions.
ping
A utility that tests the connection between two computers on a network by sending a message from one computer to the other and measuring how long it takes for the receiving system to confirm that the message was received. Typically packaged with network software.
propagate
When using IMDB Cache to send table or row modifications from an IMDB Cache to an Oracle database. Compare with "replicate".
protocol message logging
The process that the TimesTen Server uses to record each message it receives through the TimesTen network protocol.
range index
Indexes are used to speed up queries on a table. A range index is similar in functionality to a B+-tree index and is best used for retrieving rows with column values within a certain range.
replicate
The sending of table or row modifications from one database to another. Compare with "propagate".
rollback
To undo the actions of a transaction, thereby returning all items modified by the transaction to their original state.
row buffering
A performance enhancement used by the TimesTen Client in which the client receives multiple result rows of an SQL query in each message from the TimesTen Server to reduce network communication.
scalability
The degree to which a system or application can handle increasing demands on system resources without significant performance degradation.
A schema is automatically created for a user upon user creation. A schema is the namespace for a given user, where all objects owned by this user belong and all objects are identified by schema qualified names. For example, user PAT belongs to the PAT schema. In addition, the object EMPLOYEES owned by PAT is identified as PAT.EMPLOYEES.
If a user refers to an object without the schema name, TimesTen first tries to resolve the name to the user's schema. If this object does not exist, TimesTen tries to resolve the name to SYS.EMPLOYEES.
A user always has all privileges to all objects in their own schema. These privileges can never be revoked.
shorthand name
A logical name used to refer to a particular TimesTen Server. Shorthand names relieve the end user of having to enter a host name and port number to connect to a TimesTen Server.
SMP
Symmetric multi-processing. A hardware configuration in which two or more similar processors are connected via a high-bandwidth link and managed by one operating system, where each processor has equal access to I/O devices.
stack overflow condition
An error condition in which the stack usage of a thread or process exceeds the amount of space allocated for the stack.
stored procedure
An executable object or named entity stored in a database that can be invoked with input and output parameters and which can return result sets similar to those returned by an SQL query.
system account
A special account on Windows used by the operating system and certain operating system services. The TimesTen service and the TimesTen Server run under the system account.
TCP/IP
The communications protocol used by computers on the Internet. Abbreviation for Transport Control Protocol/Internet Protocol.
TCP/IP port number
A number used by TCP/IP that identifies the end point for a connection to a host that supports multiple simultaneous connections.
telnet
A utility program and protocol that enables a user on one computer to open a virtual terminal, log in to a remote host and interact as a terminal user of that host.
thread-safe ODBC driver
An ODBC driver that supports multithreaded servers and clients. The TimesTen data manager driver and the TimesTen Client driver are thread-safe.
timeout error
An error condition indicating that the requested operation did not complete within the given amount of time. See also "timeout interval".
timeout interval
A configuration parameter that specifies the maximum amount of time that an operation should take to complete. See also "timeout error".
TimesTen Client
(1) An ODBC driver that enables end users to access data sources through a TimesTen Server. (2) A computer on which the TimesTen Client software has been installed. Using the TimesTen Client driver, an end user or application can access any data source managed by an available TimesTen Server.
TimesTen Client/Server network protocol
The protocol used by TimesTen Clients and TimesTen Servers to exchange data over a standard TCP/IP network connection.
TimesTen Data Server
(1) An application program that makes TimesTen data sources available to the TimesTen Clients on a network. (2) A computer on which the TimesTen Data Server software is running.
TimesTen Server address
The host name or IP address used during installation of the TimesTen Server to identify the computer on which the software is being installed.
transaction
An operation or set of operations performed against data in a database. The operations defined in a transaction must be completed as a whole; if any part of the transaction fails, the entire transaction fails. See also "ACID transaction semantics".
UCS-4
A fixed-width, 32-bit Unicode character set. Each character occupies 32 bits of storage. The UCS-2 characters are the first 65,536 code points in this standard, so it can be viewed as a 32-bit extension of UCS-2.
UTF-16
An encoding scheme defined by the ISO/IEC 10646 standard in which each Unicode character is represented by either a two-byte integer or a pair of two-byte integers. Characters from European scripts and most Asian scripts are represented in two bytes. Surrogate pairs are represented in four bytes. Surrogate pairs represent characters such as infrequently used Asian characters that were not included in the original range of two-byte characters.
user account
The combination of a user name, password and access permissions that gives an individual user access to an operating system.
User Manager
A Windows utility program used to create user accounts and assign access rights and group membership.
Oracle TimesTen In-Memory Database is a memory-optimized relational database. Deployed in the application tier, Oracle TimesTen In-Memory Database operates on databases that fit entirely in physical memory using standard SQL interfaces. High availability for the in-memory database is provided through real-time transactional replication.
This guide provides:
Background information to help you understand how TimesTen works
Step-by-step instructions and examples that show how to perform the most commonly needed tasks
To work with this guide, you should understand how database systems work and have some knowledge of Structured Query Language (SQL).
TimesTen documentation is available on the product distribution media and on the Oracle Technology Network:
http://www.oracle.com/technetwork/products/timesten/documentation
TimesTen supports multiple platforms. Unless otherwise indicated, the information in this guide applies to all supported platforms. The term Windows refers to all supported Windows platforms. The term UNIX applies to all supported UNIX and Linux platforms. See "Platforms" in Oracle TimesTen In-Memory Database Release Notes for specific platform versions supported by TimesTen.
|
Note: In TimesTen documentation, the terms "data store" and "database" are equivalent. Both terms refer to the TimesTen database unless otherwise noted. |
This document uses the following text conventions:
| Convention | Meaning |
|---|---|
| boldface | Boldface type indicates graphical user interface elements associated with an action, or terms defined in text. |
| italic | Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values. |
monospace | Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter. |
italic monospace | Italic monospace type indicates a variable in a code example that you must replace. For example:
Replace |
| [ ] | Square brackets indicate that an item in a command line is optional. |
| { } | Curly braces indicate that you must choose one of the items separated by a vertical bar ( | ) in a command line. |
| | | A vertical bar separates alternative arguments. |
| . . . | An ellipsis (. . .) after an argument indicates that you may use more than one argument on a single command line. |
| % | The percent sign indicates the UNIX shell prompt. |
| # | The number (or pound) sign indicates the prompt for the UNIX root user. |
TimesTen documentation uses these variables to identify path, file and user names:
| Convention | Meaning |
|---|---|
TimesTen_install_dir | The path that represents the directory where the current release of TimesTen is installed. |
TTinstance | The instance name for your specific installation of TimesTen. Each installation of TimesTen must be identified at install time with a unique alphanumeric instance name. This name appears in the install path. |
bits or bb | Two digits, 32 or 64, that represent either the 32-bit or 64-bit version of the operating system. |
release or rr | The first three parts in a release number, with or without dots. The first three parts of a release number represent a major TimesTen release. For example, 1122 or 11.2.2 represents TimesTen 11g Release 2 (11.2.2). |
jdk_version | One or two digits that represent the major version number of the Java Development Kit (JDK) release. For example, 5 represents JDK 5. |
DSN | The data source name. |
For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.
Access to Oracle Support
Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.
The Oracle TimesTen Data Manager daemon, which is the Oracle TimesTen Data Manager service on Windows, starts when TimesTen is installed. The daemon operates continually in the background.
The TimesTen daemon performs the following functions:
Manages shared memory access
Coordinates process recovery
Keeps management statistics on what databases exist, which are in use, and which application processes are connected to which databases
Manages RAM policy
Starts replication processes, the TimesTen Server and the cache agent.
Application developers do not interact with the daemon directly. No application code runs in the daemon and application developers do not generally have to be concerned with it. Application programs that access TimesTen databases communicate with the daemon transparently using TimesTen internal routines.
The following sections discuss interaction with the TimesTen daemon on various platforms:
The Oracle TimesTen Data Manager service starts when you install the Oracle TimesTen Data Manager on your Windows system. To manually start and stop the Oracle TimesTen Data Manager service, you can use the ttDaemonAdmin utility with the -start or -stop option, or the Windows Administrative Tools as follows:
Open Administrative Tools:
On Windows 2000 and XP from the Start menu, select Settings, Control Panel, and finally Administrative Tools.
Double-click Services. All currently available services are displayed.
Select TimesTen Data Manager 11.2.2, then click the appropriate button to stop or start the service.
|
Note: You must have administrative privileges to start and stop the TimesTen service. |
You must be the instance administrator to start and stop the TimesTen daemon.
The instance administrator must manually start and stop the daemon, after each system reboot, unless the setuproot script has been run. To manually start and stop the TimesTen main daemon, you can use the ttDaemonAdmin utility with the -start or -stop option.
User root can start the daemon by executing the daemon startup script. The following table shows the location of the daemon startup script by platform.
| Platform | Location of daemon startup script |
|---|---|
| Linux | /etc/init.d/tt_instance_name |
| Solaris | /etc/init.d/tt_instance_name |
| AIX | /etc/init.d/tt_instance_name |
A TimesTen application consists of a database that has been allocated shared memory, user connections, and possibly replication and cache agents for communication with other TimesTen or Oracle databases.
To shut down a TimesTen application, complete the following tasks:
Disconnect all user connections gracefully.
Shut down all replication and cache agents.
Unload the database from shared memory if it was manually loaded.
Stop the TimesTen daemon.
The ttendaemon.options file contains TimesTen daemon options. During installation, the installer sets some of these options to correspond to your responses to the installation prompts.
On Windows, the ttendaemon.options file is located in the directory:
install_dir\srv\info
On UNIX, the ttendaemon.options file is located in the directory:
install_dir/info/
The features that the ttendaemon.options file controls are as follows:
The network interfaces on which the daemon listens
The minimum and maximum number of TimesTen subdaemons that can exist for the TimesTen instance
Whether or not the TimesTen Server is started
Whether or not you use shared memory segments for client/server inter-process communication
The number of Server processes that are prespawned on your system
The location and size of support and user logs
Backward compatibility
The maximum number of users for a TimesTen instance
Data access across NFS mounted systems. This is for Linux only.
The TNS_ADMIN value for the Oracle Database. This option cannot be modified in this file.
Modifying the default database recovery after a fatal error
Use the ttmodinstall utility to make changes to the ttendaemon.options file for most commonly changed options. See "ttmodinstall" in Oracle TimesTen In-Memory Database Reference. If you cannot use ttmodinstall to change a particular option and must modify the ttendaemon.options file directly, stop the TimesTen daemon before you change the file. Restart the TimesTen daemon after you have finished changing the file. To change TimesTen Server options, it is only necessary to stop the server. It is not necessary to stop the TimesTen daemon.
The rest of this section includes the following topics:
By default, the TimesTen main daemon, all subdaemons and agents listen on a socket for requests, using any available address. All TimesTen utilities and agents use the loopback address to talk to the main daemon, and the main daemon uses the loopback address to talk to agents.
The -listenaddr entry in a separate line in the ttendaemon.options file tells the TimesTen daemons to listen on the specific address indicated in the value supplied. The address specified with this option can be either a host name or a numerical IP address.
The -listenaddr parameter exists for situations where a server has multiple network addresses and multiple network cards. In this case it is possible to limit the network addresses on which the TimesTen daemon is listening to a subset of the server's network addresses. This is done by making entries only for those addresses on which the daemon listens. These possibilities exist:
Given a situation where a server has a "public" network address that is accessible both inside and outside the local network and a "private" address that is accessible only within the local network, adding a -listenaddr entry containing only the private address blocks all communications to TimesTen coming on the public address.
By specifying only the local host, the TimesTen main daemon can be cut off from all communications coming from outside the server and communicate only with local clients and subdaemons.
There is no relationship between TimesTen replication and the -listenaddr parameter and there is no requirement for enabling the -listenaddr parameter when replication is enabled. If replication is going to be used in an environment where -listenaddr is enabled, then the replication nodes need to know the allowable network addresses to use. However, if no -listenaddr parameter is enabled replication still works.
To explicitly specify the address on which the daemons should listen on a separate line in the ttendaemon.options file, enter:
-listenaddr address
For example, if you want to restrict the daemon to listen to just the loopback address, you say either:
-listenaddr 127.0.0.1
or
-listenaddr localhost
This means that only processes on the local machine can communicate with the daemon. Processes from other machines would be excluded, so you would not be able to replicate to or from other machines, or grant client access from other machines.
If you have multiple ethernet cards on different subnets, you can specify -listenaddr entries to control which machines can connect to the daemon.
You can enter up to four addresses on which to listen by specifying the option and a value on up to four separate lines in the ttendaemon.options file. In addition to the addresses you specify, TimesTen always listens on the loopback address.
By default, TimesTen uses the IPv4 protocol. To enable the daemon to listen on IPv6, you must enter on a separate line in the ttendaemon.options file:
-enableIPv6
and
-listenaddr6 address
You can specify an IPv6 address with the -listenaddr6 option to enable IPv6.
Specifying the -enableIPv6 option with one or more -listenaddr or -listenaddr6 options adds the IPv6 loopback interface to the list.
If you specify the -enableIPv6 option without specifying any addresses with the -listenaddr or -listenaddr6 options, then the daemon listens on any IPv6 interface as well as any IPv4 interface.
The address specified with this option can be either a host name or a numerical IP address. See "Determining the daemon listening address" for specifics on the -listenaddr option
If one or more -listenaddr options are provided, the daemons listen on the specified IPv4 interfaces, with the IPv4 loopback address being added to the list if not specified. If only -enableIPv6 is specified, the daemons listen on both the IPv4 ANY interface and the IPv6 ANY interface.
You can specify both -listenaddr and -listenaddr6 options. If you specify one or more -listenaddr6 options, the daemons listen on the specified IPv4 or IPv6 interfaces, with both the IPv4 and IPv6 loopback interfaces being added if not specified. If the name resolver returns multiple IPv4 and/or IPv6 addresses for a name, the daemons listen on all of the names.
As the daemon operates, it generates error, warning, and informational messages. These messages may be useful for TimesTen system administration and for debugging applications.
By default, informational messages are stored in the following:
A user error log that contains information you may need to see. Generally, these messages contain information on actions you may need to take.
A support log containing everything in the user error log plus information of use by TimesTen Customer Support.
The following options specify the locations and size of the support and user logs, as well as the number of files to keep stored on your system.
If you have specified the Event Log as the location for your log messages, to view them follow these steps:
Open the Event Viewer window. From the Start menu, select Control Panel, Administrative Tools, and then select Event Viewer.
In the Event Viewer list, choose Applications and Services Logs.
The window displays log messages generated by applications. Any messages with the word "TimesTen" in the "Source" column were generated by the Oracle TimesTen Data Manager service.
To view any TimesTen message, double-click the message summary.
The message window is displayed. You can view additional messages by clicking Next , Previous, up or down arrows, depending on your version of Windows.
|
Note: You can also view messages using thettDaemonLog utility. |
To specify the syslog facility used to log TimesTen daemon and subdaemon messages on UNIX, on a separate line of the ttendaemon.options file add:
-facility name
Possible name values are: auth, cron, daemon, local0-local7, lpr, mail, news, user, or uucp.
To turn off detailed log messages, add a # before -verbose in the ttendaemon.options file.
TimesTen uses subdaemons to perform the following:
Manage databases.
Flush the transaction log buffer to disk.
Perform periodic checkpoints.
Implement the aging policies of various tables.
Find and break deadlocks.
Rollback transactions for abnormally terminated direct-mode applications.
Perform required background processing for the database.
The main TimesTen daemon spawns subdaemons dynamically as they are needed. You can manually specify a range of subdaemons that the daemon may spawn, by specifying a minimum and maximum.
At any point in time, one subdaemon is potentially needed for TimesTen process recovery for each failed application process that is being recovered at that time.
By default, TimesTen spawns a minimum of 4 subdaemons and specifies the default maximum number of subdaemons at 50. However, you can change these settings by assigning new values to the -minsubs and -maxsubs options in the ttendaemon.options file.
By default, TimesTen systems cannot access data across NFS-mounted systems. On Linux x86 64-bit systems, you can access checkpoint and transaction log files on NFS-mounted systems.
To enable data access on NFS-mounted systems, on a separate line of the ttendaemon.options file, add:
-allowNetworkFiles
|
Note: TimesTen does not support the storage of trace files or user and support logs across NFS-mounted systems |
This section includes the following topics:
The TimesTen Server is a child process of the TimesTen daemon that operates continually in the background. To modify the TimesTen Server options, you must do the following:
Stop the TimesTen Server.
Modify the options in the ttendaemon.options file as described in the following sections.
Restart the TimesTen Server.
The -server portno entry in a separate line in the ttendaemon.options file tells the TimesTen daemon to start the TimesTen Server and what port to use. The portno is the port number on which the server will listen.
If the TimesTen Server is installed, you can enable or disable the TimesTen Server:
To enable the TimesTen Server, remove the comment symbol '#' in front of the -server portno entry.
To disable the TimesTen Server, add a comment symbol '#' in front of the -server portno entry.
Each TimesTen Client connection requires one server process. By default, a server process is spawned when a client requests a connection.
You can prespawn a pool of reserve server processes, making them immediately available for a client connection, thus improving client/server connection performance.
The -serverpool number entry in a separate line in the ttendaemon.options file on the Server machine tells the TimesTen Server to create number processes. If this option is not specified, no processes are prespawned and kept in the reserve pool.
When a new connection is requested, if there are no items in the server pool, a new process is spawned, as long as you have not met the operating system limit.
If you request more process than allowed by your operating system, a warning is returned. Regardless of the number of processes requested, an error does not occur unless a client requests a connection when no more are available on the system, even if there are no processes remaining in the reserve pool.
Changes to the TimesTen Server take effect when the Server is restarted.
By default, TimesTen creates only one connection to a Server for each child process. You can set multiple connects to a single TimesTen Server, either by using the Server connection attributes described in the Oracle TimesTen In-Memory Database Reference or by setting the TimesTen daemon options described in this section. These options enable you to set the number of connections to a TimesTen Server, the number of servers for each DSN and the size of each connection to the server.
Changes to TimesTen Server settings do not occur until the TimesTen server is restarted. To restart the Server, use the following command:
ttDaemonAdmin -restartserver
|
Note: In the case that you have set both the Server connection attributes and these daemon options, the value of the Server connection attributes takes precedence. |
To run a child server process in multithreaded mode so that a single server process can service multiple client connections to a database, add the following line to the ttendaemon.options file:
-maxConnsPerServer NumberOfClientConnections
The possible values of NumberOfClientConnections range from 1 to 2047, inclusive. The default value is 1, which indicates that the child server process runs in multi-process mode and, therefore, can service only one client connection.
To specify the desired number of child server processes to be spawned for a particular server DSN, add the following line to the ttendaemon.options file:
-serversPerDSN NumberOfChildServerProcesses
The possible values of NumberOfChildServerProcesses range from 1 to 2047, inclusive. The default value is 1.
Client connections to a particular server DSN are evenly distributed in round-robin fashion to the child server processes that are spawned and assigned to the DSN. The number of child server processes assigned to the server DSN is greater than NumberOfChildServerProcesses if the number of client connections to the DSN is greater than the maximum number of client connections per child server process multiplied by the desired number of child server processes spawned for a server DSN.
To set the size of the child server process thread stack for each client connection, add the following line to the ttendaemon.options file:
-serverStackSize ThreadStackSize
ThreadStackSize is specified in KB. The default is 128 KB on 32-bit systems and 256 KB on 64-bit systems. The ThreadStackSize setting is ignored if the maximum number of client connections per child server process is 1 because the sole client connection will be serviced by the main thread of the child server process.
|
Note: These changes to the TimesTen Server do not occur until the TimesTen daemon is restarted. |
By default, TimesTen uses TCP/IP communication between applications linked with the TimesTen Client driver and the TimesTen Server.
Where the client application resides on the same machine as the TimesTen Server, you can alternatively use shared memory for the inter-process communication (IPC).
This can be useful for performance purposes or to allow 32-bit client applications to communicate with a 64-bit database on the server. Before using shared memory as IPC verify that you have configured your system correctly. See "Installation prerequisites" in Oracle TimesTen In-Memory Database Installation Guide.
The -serverShmIpc entry in a separate line in the ttendaemon.options file tells the TimesTen Server to accept a client connection that intends to use a shared memory segment for IPC.
If this entry is missing, add this line to the ttendaemon.options file to start the TimesTen Server with shared memory IPC capability when the TimesTen daemon is restarted.
If the entry exists, add the # symbol before the line in the ttendaemon.options file to comment it out. The TimesTen Server is no longer started with shared memory IPC capability when the TimesTen daemon starts.
The -serverShmSize size entry in a separate line in the ttendaemon.options file tells the TimesTen Server to create a shared memory segment of the specified size in MB.
If this entry is missing, the TimesTen Server creates a shared memory segment of 64MB.
An appropriate value for the shared memory segment depends on:
The expected number of concurrent client/server connections to all databases that belong to an instance of the TimesTen Server.
The number of concurrent allocated statements within each such connection.
The amount of data being transmitted for a query.
Some guidelines for determining the size of the shared memory segment include:
The maximum size allowed is 1 gigabyte.
TimesTen needs 1 MB of memory for internal use.
Each connection needs a fixed block of 16 KB.
Each statement starts with a block of 16 KB for the IPC. But this size is increased or decreased depending upon the size of the data being transmitted for a query. TimesTen increments the statement buffer size by doubling it and decreases it by halving it.
For example, if the user application anticipates a max of 100 simultaneous shared-memory-enabled client/server connections, and if each connection is anticipated to have a maximum of 50 statements, and the largest query returns 128 KB of data, use this formula to configure the serverShmSize:
serverShmSize = 1 MB + (100 * 16) KB + (100 * 50 * 128) KB
= 1 MB + 2 MB + 625 MB = 628 MB
This is the most memory required for this example. The entire memory segment would be used only if all 100 connections have 50 statements each and each statement has a query that returns 128 KB of data in a row of the result.
In this example, if you configured the serverShmSize to 128 MB, either a new shared-memory-enabled client/server connection is refused by the TimesTen Server or a query may fail due to lack of resources within the shared memory segment.
Once configured, to change the value of the shared memory segment you must stop the TimesTen Server. Stopping the server detaches all existing client/server connections to any database that is associated with that instance of the TimesTen Server. The steps for modifying the value of the -serverShmSize option are:
The -noserverlog entry in a separate line in the ttendaemon.options file tells the TimesTen daemon to turn off logging of connects and disconnects from the client applications.
If the TimesTen Server is installed, you can enable or disable logging of connect and disconnect messages by:
To enable logging, add a comment symbol '#' before the -noserverlog entry.
To disable logging, remove the comment symbol '#' before the -noserverlog entry.
An application using the TimesTen Data Manager should obtain an order of magnitude performance improvement in its data access over an application using a traditional DBMS. However, poor application design and tuning can erode the TimesTen advantage. This chapter discusses factors that can affect the performance of a TimesTen application. These factors range from subtle, such as data conversions, to more overt, such as preparing a command at each execution.
This chapter explains the full range of these factors, with a section on each factor indicating:
How to detect problems.
How large is the potential performance impact.
Where are the performance gains.
What are the tradeoffs.
The following sections describe how to tune and identify performance issues:
|
Note: You can also identify performance issues by examining theSYS.MONITOR table. |
For information on tuning TimesTen Java applications, see "Java Application Tuning" in the Oracle TimesTen In-Memory Database Java Developer's Guide. For information on tuning TimesTen C applications, see "ODBC Application Tuning" in the Oracle TimesTen In-Memory Database C Developer's Guide.
The following sections include tips for tuning your system and databases:
Performance impact: Large
Configure your system so that the entire database fits in main memory. The use of virtual memory substantially decreases performance. You will know that the database or working set does not fit if a performance monitoring tool shows excessive paging or virtual memory activity.
You may have to add physical memory or configure the system software to allow a large amount of shared memory to be allocated to your process(es). TimesTen includes the ttSize utility to help you estimate the size of your database. For more information, see "ttSize" in the Oracle TimesTen In-Memory Database Reference.
Performance impact: Variable
When you create a database, you are required to specify a database size. Specifically, you specify sizes for the permanent and temporary partitions of the database. For details on how to size the database and shared memory, see "Specifying the size of a database".
Performance impact: Variable
The PL/SQL runtime system uses an area of shared memory to hold metadata about PL/SQL objects in TimesTen and the executable code for PL/SQL program units that are currently being executed or that have recently been executed. The size of this shared memory area is controlled by the PLSQL_MEMORY_SIZE first connect attribute.
|
Note: For more information onPLSQL_MEMORY_SIZE first connect attribute, see "PL/SQL first connection attributes" in the Oracle TimesTen In-Memory Database Reference. |
When a new PL/SQL program unit is prepared for execution, it is loaded into shared memory. If shared memory space is not available, the cached recently-executed program units are discarded from memory until sufficient shared memory space is available. If all of the PL/SQL shared memory is being used by currently executing program units, then attempts by a new connection to execute PL/SQL may result in out of space errors, such as ORA-04031. If this happens, increase the PLSQL_MEMORY_SIZE.
Even if such out of space errors do not occur, the PLSQL_MEMORY_SIZE may be too small. It is less expensive in CPU time to execute a PL/SQL procedure that is cached in shared memory than one that is not cached. In a production application, the goal should be for PLSQL_MEMORY_SIZE to be large enough so that frequently-executed PL/SQL units are always cached. The TimesTen built-in procedure ttPLSQLMemoryStats can be used to determine how often this occurs. The PinHitRatio value returned is a real number between 0 and 1.
1.0: A value of 1.0 means that every PL/SQL execution occurred from the cache.
0.0: A value of 0.0 means that every execution required that the program unit be loaded into shared memory.
The proper value of PLSQL_MEMORY_SIZE for a given application depends on the application. If only a small number of PL/SQL program units are repeatedly executed, then the size requirements can be small. If the application uses hundreds of PL/SQL program units, memory requirements increase.
Performance increases dramatically as the PinHitRatio goes up. In one set of experiments, an application program repeatedly executed a large number of PL/SQL stored procedures. With a larger value for PLSQL_MEMORY_SIZE, the application results in a PinHitRatio of around 90%, and the average execution time for a PL/SQL procedure was 0.02 seconds. With a smaller value for PLSQL_MEMORY_SIZE, there was more contention for the cache, resulting in a PinHitRatio of 66%. In this experiment the average execution time was 0.26 seconds.
The default value for PLSQL_MEMORY_SIZE is 32 MBs. This should be sufficient for several hundred PL/SQL program units of reasonable complexity to execute. After running a production workload for some time, check the value of PinHitRatio. If it is less than 0.90, consider increasing PLSQL_MEMORY_SIZE.
Performance impact: Large
Increasing the value of LogBufMB can have a substantial positive performance impact. If LOG_BUFFER_WAITS is increasing, increase the value of LogBufMB.
The trade-off is that more transactions are buffered in memory and may be lost if the process crashes. If DurableCommits are enabled, increasing the default LogBufMB value does not improve performance.
Performance impact: Variable
A TimesTen database may be permanent or temporary. A temporary database disappears when the last connection goes away or when there is a system or application failure. For information on temporary databases, see "Database overview".
If you do not need to save the database to disk, you can save checkpoint overhead by creating a temporary database.
Temporary databases are never fully checkpointed to disk, although the transaction log is periodically written to disk. The amount of data written to the transaction log for temporary databases is less than that written for permanent databases, allowing better performance for temporary databases. Checkpoint operations can have significant overhead for permanent databases, depending on database size and activity, but have very little impact for temporary databases. Checkpoints are still necessary to remove transaction log files.
Performance impact: Large
By default, TimesTen loads an idle database, which is a database with no connections, into memory when a first connection is made to it. When the final application disconnects from a database, a delay occurs when the database is written to disk. If applications are continually connecting and disconnecting from a database, the database may be loaded to and unloaded from memory continuously, resulting in excessive disk I/O and poor performance. Similarly, if you are using a very large database you may want to pre-load the database into memory before any applications attempt to use it.
To avoid the latency of loading a database into memory, you can change the RAM policy of the database to allow databases to always remain in memory. The trade-off is that since the database is never unloaded from memory, a final disconnect checkpoint never occurs. So, applications should checkpoint the database explicitly in order to reduce the disk space taken up by transaction log files.
Alternatively, you can specify that the database remain in memory for a specified interval of time and accept new connections. If no new connections occur in this interval, TimesTen unloads the database from memory and checkpoints it. You can also specify a setting to enable a system administrator to load and unload the database from memory manually.
To change the RAM policy of a database, use the ttAdmin utility. For more details on the RAM policy and the ttAdmin utility, see "Specifying a RAM policy" and "ttAdmin" in the Oracle TimesTen In-Memory Database Reference.
Performance impact: Large
When you duplicate a database, use the -ramLoad option of the ttAdmin utility. This places the database in memory, available for connections, instead of unloading it with a blocking checkpoint. For more information, see "Avoid connection overhead" and "ttAdmin" in the Oracle TimesTen In-Memory Database Reference..
Database contention can substantially impede application performance.
To reduce contention in your application:
Choose the appropriate locking method. See "Choose the best method of locking".
Distribute data strategically in multiple tables or databases.
If your application suffers a decrease in performance because of lock contention and a lack of concurrency, reducing contention is an important first step in improving performance.
The LOCK_GRANTS_IMMED, LOCK_GRANTS_WAIT and LOCK_DENIALS_COND columns in the SYS.MONITOR table provide some information on lock contention:
LOCK_GRANTS_IMMED counts how often a lock was available and was immediately granted at lock request time.
LOCK_GRANTS_WAIT counts how often a lock request was granted after the requestor had to wait for the lock to become available.
LOCK_DENIALS_COND counts how often a lock request was not granted because the requestor did not want to wait for the lock to become available.
If limited concurrency results in a lack of throughput, or if response time is an issue, an application can serialize JDBC calls to avoid contention. This can be achieved by having a single thread issue all those calls. Using a single thread requires some queuing and scheduling on the part of the application, which has to trade off some CPU time for a decrease in contention and wait time. The result is higher performance for low-concurrency applications that spend the bulk of their time in the database.
Performance impact: Medium
All of the TimesTen platform operating systems implement a dynamic file system buffer pool in main memory. If this buffer pool is allowed to be large, TimesTen and the operating system both retain a copy of the file in memory, causing some of the TimesTen shared segment to be paged out.
This behavior may not occur for databases that are less than half of the installed memory size. On some systems, it is possible to limit the amount of main memory used by the file system. On other systems, this effect is less pronounced.
On AIX, you can avoid paging by configuring large pages, which locks the shared segment into memory so it cannot be paged. See "Large pages" in the Oracle TimesTen In-Memory Database Installation Guide for details on how to configure large pages on AIX.
Performance impact: Medium
During special operations such as initial loading, you can choose different options than you would use during normal operations. In particular, consider using database-level locking for bulk loading; an example would be using ttBulkCp or ttMigrate. These choices can improve loading performance by a factor of two.
An alternative to database-level locking is to exploit concurrency. Multiple copies of ttBulkCp -i can be run using the -notblLock option. Optimal batching for ttBulkCp occurs by adding the -xp 256 option. ttMigrate can be run with -numThreads option to load individual or multiple tables concurrently.
For more details, see "ttBulkCp" and "ttMigrate" in the Oracle TimesTen In-Memory Database Reference.
Performance impact: Large
There are two versions of the TimesTen Data Manager driver for each platform: a debug and production version. Unless you are debugging, use the production version. The debug library can be significantly slower. See "Specify the Data Manager DSN" and "Specify the ODBC driver" for a description of the TimesTen Data Manager drivers for the different platforms.
On Windows, make sure that applications that use the ODBC driver manager use a DSN that accesses the correct TimesTen driver. Make sure that applications are linked with the correct TimesTen driver. For direct connect applications, use the TimesTen Data Manager driver. An application can call the ODBC SQLGetInfo function with the SQL_DRIVER_NAME argument to determine which driver it is using.
Performance impact: Large
Both ODBC and JDBC provide a trace facility to help debug applications. For performance runs, make sure that tracing is disabled except when debugging applications.
To turn the JDBC tracing on, use:
DriverManager.setLogStream method: DriverManager.setLogStream(new PrintStream(System.out, true));
By default tracing is off. You must call this method before you load a JDBC driver. Once you turn the tracing on, you cannot turn it off for the entire execution of the application.
Performance impact: Variable
JRockit and IBM provide JVMs that may perform better than the Sun JVM.
Performance impact: Large
If you are planning a replication scheme, ensure the following:
The transaction log setting for LogBufMB should result in the value of LOG_FS_READS in the SYS.MONITOR table being 0 or close to 0. This ensures that the replication agent does not have to read any transaction log records from disk. If the value of LOG_FS_READS is increasing, then increase the transaction log buffer size.
CPU resources are adequate. The replication agent on the master database will spawn a thread for every subscriber database. Each thread reads and processes the transaction log independently and needs adequate CPU resources to make progress.
If the sending side and receiving side of the replication scheme are mismatched in CPU power, place the replication receiver on the faster system.
Performance impact: Medium
Use the RecoveryThreads first connection attribute to increase the number of threads that apply changes from the active master database to the standby master database from 1 to 2. If you set RecoveryThreads to 2 on the standby, you should also set it to 2 on the active to maintain increased throughput if there is a failover.
You can also set RecoveryThreads to 2 on one or more read-only subscribers in an active standby pair to increase replication throughput from the standby master database.
Databases must be hosted on systems that are 2-way or larger to take advantage of setting this attribute to 2.
Performance impact: Variable
If character set conversion is requested when migrating databases, performance may be slower than if character set conversion is not requested.
The following sections include tips for Client/Server tuning:
You can analyze your Client/Server performance with the following statistics that are tracked in the SYS.SYSTEMSTATS table:
|
Note: For more details on theSYS.SYSTEMSTATS table, see "SYS.SYSTEMSTATS" in the Oracle TimesTen In-Memory Database System Tables and Views Reference. |
Total number of executions from a Client/Server application.
Total number of INSERT, UPDATE, DELETE, SELECT, MERGE, ALTER, CREATE, DROP statements executed by the server.
Total number of transactions committed or rolled back by the server.
Total number of table rows inserted, updated, or deleted by the server.
Total number of Client/Server roundtrips.
Total number of bytes transmitted or received by the server.
Total number of Client/Server disconnects.
Performance impact: Large
Using TimesTen Client to access databases on a remote server machine adds network overhead to your connections. Whenever possible, write your applications to access the TimesTen Data Manager locally, and link the application directly with the TimesTen Data Manager.
By default, connections wait 10 seconds to acquire a lock. To change the timeout interval for locks, use the ttLockWait built-in procedure.
For more details, see "ttLockWait" in the Oracle TimesTen In-Memory Database Reference.
When multiple connections access a database simultaneously, TimesTen uses locks to ensure that the various transactions operate in apparent isolation. TimesTen supports the isolation levels described in Chapter 8, "Transaction Management and Recovery". It also supports the locking levels: database-level locking, table-level locking and row-level locking. You can use the LockLevel connection attribute to indicate whether database-level locking or row-level locking should be used. Use the ttOptSetFlag procedure to set optimizer hints that indicate whether table locks should be used. The default lock granularity is row-level locking.
|
Note: For more information, see "LockLevel" and "ttOptSetFlag" in the Oracle TimesTen In-Memory Database Reference. |
If there is very little contention on the database, use table-level locking. It provides better performance and deadlocks are less likely. There is generally little contention on the database when transactions are short or there are few connections. In that case, transactions are not likely to overlap.
Table-level locking is also useful when a statement accesses nearly all the rows on a table. Such statements can be queries, updates, deletes or multiple inserts done in a single transaction.
TimesTen uses table locks only with Serializable isolation. If your application specifies table locks with any other isolation levels, TimesTen overrides table-level locking and uses row locks. However, the optimizer plan may still display table-level locking hints.
Database-level locking restricts concurrency more than table-level locking, and is generally useful only for initialization operations, such as bulk-loading, when no concurrency is necessary. It has better response-time than row-level or table-level locking, at the cost of diminished throughput.
Row-level locking is generally preferable when there are many concurrent transactions that are not likely to need access to the same row.
When using row-level locking, applications can run transactions at the SERIALIZABLE or READ_COMMITTED isolation level. The default isolation level is READ_COMMITTED. You can use the Isolation connection attribute to specify one of these isolation levels for new connections.
When running at SERIALIZABLE transaction isolation level, TimesTen holds all locks for the duration of the transaction.
Any transaction updating a row blocks writers until the t €ÿransaction commits.
Any transaction reading a row blocks out writers until the transaction commits.
When running at READ_COMMITTED transaction isolation level, TimesTen only holds update locks for the duration of the transaction.
Any transaction updating a row blocks out writers to that row until the transaction commits. A reader of that row receives the previously committed version of the row.
Phantoms are possible. A phantom is a row that appears during one read but not during another read, or appears in modified form in two different reads, in the same transaction, due to early release of read locks during the transaction.
You can determine if there is an undue amount of contention on your system by checking for time-out and deadlock errors (errors 6001, 6002, and 6003). Information is also available in the LOCK_TIMEOUTS and DEADLOCKS columns of the SYS.MONITOR table.
For more details on isolation levels, see "Transaction isolation levels".
Performance impact: Variable
The TimesTen Client normally communicates with TimesTen Server using TCP/IP sockets. If both the TimesTen Client and TimesTen Server are on the same machine, client applications show improved performance by using a shared memory segment or a UNIX domain socket for inter-process communication (IPC).
To use a shared memory segment as IPC, you must set the server options in the ttendaemon.options file. For a description of the server options, see "Modifying the TimesTen Server options".
In addition, applications that use shared memory for IPC must use a logical server name for the Client DSN with ttShmHost as the Network Address. For more information, see "Creating and configuring Client DSNs on UNIX".
This feature may require a significant amount of shared memory. The TimesTen Server pre-allocates the shared memory segment irrespective of the number of existing connections or the number of statements within all connections.
If your application is running on a UNIX machine and you are concerned about memory usage, the applications using TimesTen Client ODBC driver may improve the performance by using UNIX domain sockets for communication. The performance improvement when using UNIX domain sockets is not as large as when using ShmIPC.
Applications that take advantage of UNIX domain sockets for local connections must use a logical server name for the Client DSN with ttLocalHost as the Network Address. For more information, see "Creating and configuring Client DSNs on UNIX". In addition, make sure that your system kernel parameters are configured to allow the number of connections you require. See "Installation prerequisites" in the Oracle TimesTen In-Memory Database Installation Guide.
Performance impact: Variable
Enable TT_PREFETCH_CLOSE for serializable transactions in client/server applications. In Serializable isolation mode, all transactions should be committed when executed, including read-only transactions. When TT_PREFETCH_CLOSE is enabled, the server closes the cursor and commits the transaction after the server has fetched the entire result set for a read-only query. The client should still call SQLFreeStmt(SQL_CLOSE) and SQLTransact(SQL_COMMIT), but the calls are executed in the client and do not require a network round trip between the client and server. TT_PREFETCH_CLOSE enhances performance by decreasing the network traffic between client and server.
Do not use multiple statement handles when TT_PREFETCH_CLOSE is enabled. The server may fetch all of the result set, commit the transaction, and close the statement handle before the client is finished, resulting in the closing of all statement handles.
The following example shows how to use the TT_PREFETCH_CLOSE option with ODBC and JDBC. This example sets TT_PREFETCH_CLOSE with the SQLSetConnectOption ODBC function. You can also set it with the SQLSetStmtOption ODBC function.
SQLSetConnectOption (hdbc, TT_PREFETCH_CLOSE, TT_PREFETCH_CLOSE_ON);
SQLExecDirect (hstmt, "SELECT * FROM T", SQL_NTS);
while (SQLFetch (hstmt) != SQL_NO_DATA_FOUND)
{
// do the processing
}
SQLFreeStmt (hstmt, SQL_CLOSE);
This example shows how to enable the TT_PREFETCH_CLOSE option with JDBC:
con = DriverManager.getConnection ("jdbc:timesten:client:" + DSN);
stmt = con.createStatement();
import com.timesten.sql
...
...
con.setTtPrefetchClose(true);
rs = stmt.executeQuery("select * from t");
while(rs.next())
{
// do the processing
}
import com.timesten.sql
....
try {
((TimesTenConnection)con).setTtPrefetchClose(true);
}
catch (SQLException) {
...
}
rs.close();
con.commit();
Performance impact: Large
An application can make a call to SQLTransact with either SQL_NULL_HDBC and a valid environment handle:
SQLTransact (ValidHENV, SQL_NULL_HDBC, fType)
or a valid connection handle:
SQLTransact (SQL_NULL_HENV, ValidHDBC, fType).
If the intention of the application is simply to commit or rollback on a single connection, it should use a valid connection handle when calling SQLTransact.
After you have determined the overall locking and I/O strategies, make sure that the individual SQL statements are executed as efficiently as possible. The following sections describe how to streamline your SQL statements:
Performance impact: Large
Verify that all statements are executed efficiently. For example, use queries that reference only the rows necessary to produce the required result set. If only col1 from table t1 is needed, use the statement:
SELECT col1 FROM t1...
instead of using:
SELECT * FROM t1...
Chapter 10, "The TimesTen Query Optimizer" describes how to view the plan that TimesTen uses to execute a statement. Alternatively, you can use the ttIsql showplan command to view the plan. View the plan for each frequently executed statement in the application. If indexes are not used to evaluate predicates, consider creating new indexes or rewriting the statement or query so that indexes can be used. For example, indexes can only be used to evaluate WHERE clauses when single columns appear on one side of a comparison predicate (equalities and inequalities), or in a BETWEEN predicate.
If this comparison predicate is evaluated often, it would therefore make sense to rewrite
WHERE c1+10 < c2+20
to
WHERE c1 < c2+10
and create an index on c1.
The presence of indexes does slow down write operations such as UPDATE, INSERT, DELETE and CREATE VIEW. If an application does few reads but many writes to a table, an index on that table may hurt overall performance rather than help it.
The FIRST keyword can be used to operate on a specific number of rows in the SQL statements, SELECT, UPDATE and DELETE. This attribute can improve throughput and response time. Alternatively, if an application plans to fetch at most one row for a query, and a unique index is not being used to fetch the row, the application should set SQL_MAX_ROW_COUNT to 1. See the Oracle TimesTen In-Memory Database Reference.
Occasionally, the system may create a temporary index to speed up query evaluation. If this happens frequently, it is better for the application itself to create the index. The CMD_TEMP_INDEXES column in the MONITOR table indicates how often a temporary index was created during query evaluation.
If you have implemented time-based aging for a table or cache group, create an index on the timestamp column for better performance of aging. See "Time-based aging".
Performance impact: Variable
The TimesTen Data Manager supports hash, range, and bitmap indexes. Each index structure has a different strength.
Hash indexes are created when you supply the UNIQUE HASH clause for the CREATE TABLE or ALTER TABLE statements. Hash indexes require that the table have a primary key.
Range indexes are created by default with the CREATE TABLE statement or created with the CREATE INDEX statement. Range indexes can speed up exact key lookups but are more flexible and can speed up other queries as well. Select a range index if your queries include LESS THAN or GREATER THAN comparisons. Range indexes are effective for high-cardinality data: that is, data with many possible values, such as CUSTOMER_NAME or PHONE_NUMBER.
Range indexes can also be used to speed up "prefix" queries. A prefix query has equality conditions on all but the last key column that is specified. The last column of a prefix query can have either an equality condition or an inequality condition.
Consider the following table and index definitions:
CREATE TABLE T(i1 integer, i2 integer, i3 integer, ...); CREATE INDEX IXT on T(i1, i2, i3);
The index IXT can be used to speed up the following queries:
SELECT * FROM T WHERE i1>12; SELECT * FROM T WHERE i1=12 and i2=75; SELECT * FROM T WHERE i1=12 and i2 BETWEEN 10 and 20; SELECT * FROM T WHERE i1=12 and i2=75 and i3>30;
The index IXT will not be used for queries like:
SELECT * FROM T WHERE i2=12;
because the prefix property is not satisfied. There is no equality condition for i1.
The index IXT will be used, but matching will only occur on the first two columns for queries like:
SELECT * FROM T WHERE i1=12 and i2<50 and i3=630;
Range indexes have a dynamic structure that adjusts itself automatically to accommodate changes in table size. A range index can be either unique or non-unique and can be declared over nullable columns. It also allows the indexed column values to be changed once a record is inserted. A range index is likely to be more compact than an equivalent hash index.
Bitmap indexes are created with the CREATE INDEX statement. Bitmap indexes are performant when searching and retrieving data from columns with low cardinality. Bitmap indexes are useful with equality queries, especially when using the AND and OR operators. These indexes increase the performance of complex queries that specify multiple predicates on multiple columns connected by AND and OR operators. Bitmap indexes are widely used in data warehousing environments. The environments typically have large amounts of data and ad hoc queries, but a low level of concurrent DML transactions. Bitmap indexes are compressed and have smaller storage requirements than other indexing techniques. For more details on when to use bitmap indexes, see "CREATE INDEX" in the Oracle TimesTen In-Memory Database SQL Reference.
Performance impact: Variable
TimesTen uses hash indexes to enforce primary key constraints. The number of buckets used for the hash index is determined by the PAGES parameter specified in the UNIQUE HASH ON clause of the CREATE TABLE statement. The value for PAGES should be the expected number of rows in the table divided by 256. A smaller value may result in a greater number of collisions, decreasing performance, while a larger value may provide somewhat increased performance at the cost of extra space used by the index.
If the number of values to be indexed varies dramatically, it is best to err on the side of a large index. If the size of a table cannot be accurately predicted, consider using a range index with CREATE INDEX. Also, consider the use of unique indexes when the indexed columns are large CHAR or binary values or when many columns are indexed. Unique indexes may be faster than hash indexes in these cases.
If the performance of record inserts degrades as the size of the table gets larger, it is very likely that you have underestimated the expected size of the table. You can resize the hash index by using the ALTER TABLE statement to reset the PAGES value in the UNIQUE HASH ON clause.
Performance impact: Variable
The declaration of a foreign key has no performance impact on SELECT queries, but it slows down the INSERT and UPDATE operations on the table that the foreign key is defined on and the UPDATE and DELETE operations on the table referenced by the foreign key. The slow down is proportional to the number of foreign keys that either reference or are defined on the table.
Performance impact: Large
If statistics are available on the data in the database, the TimesTen optimizer uses them when preparing a command to determine the optimal path to the data. If there are no statistics, the optimizer uses generic guesses about the data distribution.
You should compute statistics before preparing your statements, since the information is likely to result in a more efficient query optimizer plan. When gathering statistics, you need to determine when and how often to gather new statistics as performance is affected by the statistics collection process. The frequency of collection should balance the task of providing accurate statistics for the optimizer against the processing overhead incurred by the statistics collection process.
Since computing statistics is a time-consuming operation, you should compute statistics with the following guidelines:
Update statistics after loading your database or after major application upgrades.
Do not update statistics during a heavy transaction load.
Update statistics when there is substantial creation or alteration on tables, columns, or PL/SQL objects.
If you have created or altered a substantial number of tables, columns, or PL/SQL objects in your database, you should update the data dictionary optimizer statistics for the following system tables: SYS.TABLES, SYS.COLUMNS, and SYS.OBJ$.
When you substantially modify tables in batch operations, such as a bulk load or bulk delete, you can gather statistics on these tables as part of the batch operation.
Update statistics infrequently, such as once a week or once a month, when tables are only incrementally modified.
Update statistics as part of a regularly executed script or batch job during low transaction load times.
|
Note: For performance reasons, TimesTen does not hold a lock on tables or rows when computing statistics. |
Use the following for computing statistics: ttIsql statsupdate command, ttOptUpdateStats, or ttOptEstimateStats. Providing an empty string as the table name updates statistics for all tables in the current user's schema.
The statsupdate command within ttIsql evaluates every row of the table(s) in question and computes exact statistics.
The ttOptUpdateStats built-in procedure evaluates every row of the table(s) in question and computes exact statistics.
The ttOptEstimateStats procedure evaluates only a sampling of the rows of the table(s) in question and produces estimated statistics. This can be faster, but may result in less accurate statistics. Computing statistics with a sample of 10 percent is about ten times faster than computing exact statistics and generally results in the same execution plans.
|
Note: For more details onttIsql or the built-in procedures, see "ttIsql" and "Built-In Procedures" in the Oracle TimesTen In-Memory Database Replication Guide. |
Performance impact: Variable
The ALTER TABLE statement allows applications to add columns to a table and to drop columns from a table. Although the ALTER TABLE statement itself runs very quickly in most cases, the modifications it makes to the table can cause subsequent operations on the table to run more slowly. The actual performance degradation the application experiences varies with the number of times the table has been altered and with the particular operation being performed on the table.
Dropping VARCHAR2 and VARBINARY columns is slower than dropping columns of other data types since a table scan is required to free the space allocated to the existing VARCHAR2 and VARBINARY values in the column to be dropped.
Performance impact: Variable
If you can, it is recommended that you should rewrite your query to avoid nested queries that need materialization of many rows.
The following are examples of nested queries that may need to be materialized and result in multiple rows:
Aggregate nested query with groupby
Nested queries that reference rownum
Union, intersect, or minus nested queries
Nested queries with order by
For example, the following aggregate nested query results in an expensive performance impact:
select * from (select sum(x1) sum1 from t1 group by y1), (select sum(x2) sum2 from t2 group by y2) where sum1=sum2;
The following is an example of a nested query that references rownum:
select * from (select rownum rc, x1 from t1 where x1>100), (select rownum rc, x2 from t2 where x2>100) where x1=x2;
The following is an example of a union nested query:
select * from (select x1 from t1 union select x2 from t2), (select x3 from t3 group by x3) where x1=x3;
See the Oracle TimesTen In-Memory Database SQL Reference for details on subqueries.
If you have applications that generate a statement multiple times searching for different values each time, prepare a parameterized statement to reduce compile time. For example, if your application generates statements like:
SELECT A FROM B WHERE C = 10 SELECT A FROM B WHERE C = 15
You can replace these statements with the single statement:
SELECT A FROM B WHERE C = ?
TimesTen shares prepared statements automatically after they have been committed. As a result, an application request to prepare a statement for execution may be completed very quickly if a prepared version of the statement already exists in the system. Also, repeated requests to execute the same statement can avoid the prepare overhead by sharing a previously prepared version of the statement.
Even though TimesTen allows prepared statements to be shared, it is still a good practice for performance reasons to use parameterized statements. Using parameterized statements can further reduce prepare overhead, in addition to any savings from sharing statements.
Because preparing SQL statements is an expensive operation, your application should minimize the number of calls to the prepare API. Most applications prepare a set of statements at the beginning of a connection and use that set for the duration of the connection. This is a good strategy when connections are long, consisting of hundreds or thousands of transactions. But if connections are relatively short, a better strategy is to establish a long-duration connection that prepares the statements and executes them on behalf of all threads or processes. The trade-off here is between communication overhead and prepare overhead, and can be examined for each application. Prepared statements are invalidated when a connection is closed.
See "ttSQLCmdCacheInfoGet" in the Oracle TimesTen In-Memory Database Reference for related information.
TimesTen provides the ability to compress tables at the column level, which stores the data more efficiently. This mechanism provides space reduction for tables by eliminating the redundant storage of duplicate values within columns.
For more information, see "CREATE TABLE" in the Oracle TimesTen In-Memory Database SQL Reference.
The following sections include tips for improving performance of materialized views:
Performance impact: Variable
Larger numbers of join rows decrease performance. You can limit the number of join rows and the number of tables joined by controlling the join condition. For example, use only equality conditions that map one row from one table to one or at most a few rows from the other table.
Performance impact: Variable
Create indexes on the columns of the detail table that are specified in the SELECT statement that creates the join. Also consider creating an index on the materialized view itself. This can improve the performance of keeping the materialized view updated.
If an UPDATE or DELETE operation on a detail table is often based on a condition on a column, try to create an index on the materialized view on this column if possible.
For example, CustOrder is a materialized view of customer orders, based on two tables. The tables are Customer and bookOrder. The former has two columns (custNo and custName) and the latter has three columns (ordNo, book, and custNo). If you often update the bookOrder table to change a particular order by using the condition bookOrder.ordNo=const, then create an index on CustOrder.ordNo. On the other hand, if you often update based on the condition bookOrder.custNo=const, then create an index on CustOrder.custNo.
If you often update using both conditions and cannot afford to create both indexes, you may want to add bookOrder.rowId in the view and create an index on it instead. In this case, TimesTen updates the view for each detail row update instead of updating all of the rows in the view directly and at the same time. The scan to find the row to be updated is an index scan instead of a row scan, and no join rows need to be generated.
If ViewUniqueMatchScan is used in the execution plan, it is a sign that the execution may be slower or require more space than necessary. A ViewUniqueMatchScan is used to handle an update or delete that cannot be translated to a direct update or delete of a materialized view, and there is no unique mapping between a join row and the associated row in the materialized view. This can be fixed by selecting a unique key for each detail table that is updated or deleted.
Performance impact: Variable
Try not to update a join column or a GROUP BY column because this involves deleting the old value and inserting the new value.
Try not to update an expression that references more than one table. This may disallow direct update of the view because TimesTen may perform another join operation to get the new value when one value in this expression is updated.
View maintenance based on an update or delete is more expensive when:
The view cannot be updated directly. For example, not all columns specified in the detail table UPDATE or DELETE statement are selected in the view, or
There is not an indication of a one-to-one mapping from the view rows to the join rows.
For example:
CREATE MATERIALIZED VIEW v1 AS SELECT x1 FROM t1, t2 WHERE x1=x2; DELETE FROM t1 WHERE y1=1;
The extra cost comes from the fact that extra processing is needed to ensure that one and only one view row is affected due to a join row.
The problem is resolved if either x1 is UNIQUE or a unique key from t1 is included in the select list of the view. ROWID can always be used as the unique key.
Performance impact: Variable
Tï«Since outer join maintenance is more expensive when changes happen to an inner table, try to avoid changes to the inner table of an outer join. When possible, perform INSERT operations on an inner table before inserting into the associated join rows into an outer table. Likewise, when possible perform DELETE operations on the outer table before deleting from the inner table. This avoids having to convert non-matching rows into matching rows or vice versa.
Performance impact: Variable
The number of columns projected in the view SelectList can impact performance. As the number of columns in the select list grows, the time to prepare operations on detail tables increases. In addition, the time to execute operations on the view detail tables also increases. Do not select values or expressions that are not needed.
The optimizer considers the use of temporary indexes when preparing operations on detail tables of views. This can significantly slow down prepare time, depending upon the operation and the view. If prepare time seems slow, consider using ttOptSetFlag to turn off temporary range indexes and temporary hash scans.
The following sections describe how to increase performance when using transactions:
Each transaction, when it generates transaction log records (for example, a transaction that does an INSERT, DELETE or UPDATE), incurs a disk write when the transaction commits. Disk I/O affects response time and may affect throughput, depending on how effective group commit is.
Performance-sensitive applications should avoid unnecessary disk writes at commit. Use a performance analysis tool to measure the amount of time your application spends in disk writes (versus CPU time). If there seems to be an excessive amount of I/O, there are two steps you can take to avoid writes at commit:
Adjust the transaction size.
Adjust whether disk writes are performed at transaction commit. See "Use durable commits appropriately".
Long transactions perform fewer disk writes per unit of time than short transactions. However, long transactions also can reduce concurrency, as discussed in Chapter 8, "Transaction Management and Recovery".
If only one connection is active on a database, longer transactions could improve performance. However, long transactions may have some disadvantages, such as longer rollbacks.
If there are multiple connections, there is a trade-off between transaction log I/O delays and locking delays. In this case, transactions are best kept to the natural length, as determined by requirements for atomicity and durability.
By default, each TimesTen transaction results in a disk write at commit time. This practice ensures that no committed transactions are lost because of system or application failures. Applications can avoid some or all of these disk writes by performing nondurable commits. Nondurable commits do everything that a durable commit does except write the transaction log to disk. Locks are released and cursors are closed, but no disk write is performed.
|
Note: Some controllers or drivers only write data into cache memory in the controller or write to disk some time after the operating system is told that the write is completed. In these cases, a power failure may cause some information that you thought was durably committed to be lost. To avoid this loss of data, configure your disk to write to the recording media before reporting media before reporting completion or use an uninterruptible power supply. |
The advantage of nondurable commits is a potential reduction in response time and increase in throughput. The disadvantage is that some transactions may be lost in the event of system failure. An application can force the transaction log to disk by performing an occasional durable commit or checkpoint, thereby decreasing the amount of potentially lost data. In addition, TimesTen itself periodically flushes the transaction log to disk when internal buffers fill up, limiting the amount of data that will be lost.
Transactions can be made durable or can be made to have delayed durability on a connection-by-connection basis. Applications can force a durable commit of a specific transaction by calling the ttDurableCommit procedure.
Applications that do not use nondurable commits can benefit from using synchronous writes in place of write and flush. To turn on synchronous writes set the first connection attribute LogFlushMethod=2.
The XACT_D_COMMITS column of the SYS.MONITOR table indicates the number of transactions that were durably committed.
Applications that are connected to a database for a long period of time occasionally need to call the ttCkpt built-in procedure to checkpoint the database so that transaction log files do not fill up the disk. Transaction-consistent checkpoints can have a significant performance impact because they require exclusive access to the database.
It is generally better to call ttCkpt to perform a non-blocking (or "fuzzy") checkpoint than to call ttCkptBlocking to perform a blocking checkpoint. Non-blocking checkpoints may take longer, but they permit other transactions to operate against the database at the same time and thus impose less overall overhead. You can increase the interval between successive checkpoints by increasing the amount of disk space available for accumulating transaction log files.
As the transaction log increases in size (if the interval between checkpoints is large), recovery time increases accordingly. If reducing recovery time after a system crash or application failure is important, frequent checkpoints may be preferable. The DS_CHECKPOINTS column of the SYS.MONITOR table indicates how often checkpoints have successfully completed.
AUTOCOMMIT mode forces a commit after each statement, and is enabled by default. Committing each statement after execution, however, can significantly degrade performance. For this reason, it is generally advisable to disable AUTOCOMMIT, using the appropriate API for your programming environment.
The XACT_COMMITS column of the SYS.MONITOR table indicates the number of transaction commits.
|
Note: If you do not include any explicit commits in your application, the application can use up important resources unnecessarily, including memory and locks. All applications should do periodic commits. |
When transactions fail due to erroneous data or application failure, they are rolled back by TimesTen automatically. In addition, applications often explicitly rollback transactions to recover from deadlock or timeout conditions. This is not desirable from a performance point of view, as a rollback consumes resources and the entire transaction is wasted.
Applications should avoid unnecessary rollbacks. This may mean designing the application to avoid contention and checking application or input data for potential errors in advance, if possible. The XACT_ROLLBACKS column of the SYS.MONITOR table indicates the number of transactions that were rolled back.
The following sections include tips for improving performance of database recovery after database shutdown or system failure:
Performance impact: Large
Set the RecoveryThreads attribute to the number of indexes or CPUs to improve recovery performance.
The following sections include tips for improving performance for multiple CPUs:
Performance impact: Variable
One way to determine the approximate scaling you can expect from TimesTen is to run one of the scalable demo applications, such as tptbm, on your system.
The tptbm application implements a multi-user throughput benchmark. It enables you to control how it executes, including options to vary the number of processes that execute TimesTen operations and the transaction mix of SELECTs, UPDATEs, and INSERTs, for example. Run tptbm -help to see the full list of options.
By default the demo executes one operation per transaction. You can specify more operations per transaction to better model your application. Larger transactions may scale better or worse, depending on the application profile.
Run multi-processor versions of the demo to evaluate how your application can be expected to perform on systems that have multiple CPUs. If the demo scales well but your application scales poorly, you might try simplifying your application to see where the issue is. Some users comment out the TimesTen calls and find they still have bad scaling due to issues in the application.
You may also find, for example, that some simulated application data is not being generated properly, so that all the operations are accessing the same few rows. That type of localized access will greatly inhibit scalability if the accesses involve changes to the data.
See the Quick Start home page at install_dir/quickstart.html for additional information about tptbm and other demo applications. Go to the ODBC link under "Sample Programs".
Performance impact: Variable
Check the LOCK_TIMEOUTS or LOCK_GRANTS_WAIT fields in the SYS.MONITOR table. If they have high values, this may indicate undue contention, which can lead to poor scaling.
Because TimesTen is quite CPU-intensive, optimal scaling is achieved by having at most one database-intensive connection per CPU. If you have a 4-CPU system or a 2-CPU system with hyperthreading, then a 4-processor application will run well, but an 8-processor application will not perform well. The contention between the active threads will be too high. The only exception to this rule is when many transactions are committed durably. In this case, the connections are not very CPU-intensive because of the increase in I/O operations to disk, and so the machine can support many more concurrent connections.
Performance impact: Variable
Read operations scale better than write operations. Make sure that the read and write balance reflects the real-life workload of your application.
Performance impact: Variable
Prepares do not scale. Make sure that you pre-prepare commands that are executed more than once. The CMD_PREPARES and CMD_REPREPARES columns of the SYS.MONITOR table indicate how often commands were prepared or automatically re-prepared due to creation or deletion of indexes. If either has a high value, modify your application to do connection pooling, so that connects and disconnects are rare events.
Connects do not scale. Make sure that you pre-prepare commands that are executed more than once. Look at the DS_CONNECTS field in the SYS.MONITOR table. If the field has a high value, modify your application to do connection pooling, so that connects and disconnects are rare events.
Performance impact: Variable
Replication and XLA operations have significant logging overhead. Replication scales best when there are a limited number of transmitters or receivers. Check your replication topology and see if you can simplify it. Generally, XLA scales best when there are a limited number of readers. If your application has numerous readers, see if you can reduce the number.
Monitor XLA and replication to ensure they are reading from the transaction log buffer rather than from the disk. With a lot of concurrent updates, replication may not keep up. Updates are single-threaded at the subscriber. You can achieve better XLA throughput if the frequency of acknowledgements is reduced.
Estimate the number of readers and transmitters required by checking the values in the LOG_FS_READS and LOG_BUFFER_WAITS columns in the SYS.MONITOR table. The system updates this information each time a connection is made or released and each time a transaction is committed or rolled back.
Setting LogFlushMethod=2 can improve performance of RETURN TWOSAFE replication operations and RETURN RECEIPT with DURABLE TRANSMIT operations.
Performance impact: Variable
On multi-processor systems, set RecoveryThreads to minimum(number of CPUs available, number of indexes) to allow indexes to be rebuilt in parallel if recovery is necessary. If a rebuild is necessary, progress can be viewed in the user log. Setting RecoveryThreads to a number larger than the number of CPUs available can cause recovery to take longer than if it were single-threaded.
Performance impact: Variable
On multi-processor systems, if many threads are executing the same commands, then try setting PrivateCommands=1 to improve throughput or response time. The use of private commands increases the amount of temporary space used.
The following sections include tips for improving XLA performance:
A larger transaction log buffer size is appropriate when using XLA. When XLA is enabled, additional transaction log records are generated to store additional information for XLA. To ensure the transaction log buffer is properly sized, one can watch for changes in the SYS.MONITOR table entries LOG_FS_READS and LOG_BUFFER_WAITS. For optimal performance, both of these values should remain 0. Increasing the transaction log buffer size may be necessary to ensure the values remain 0.
Performance impact: Medium
Prefetching multiple update records at a time is more efficient than obtaining each update record from XLA individually. Because updates are not prefetched when you use AUTO_ACKNOWLEDGE mode, it can be slower than the other modes. If possible, you should design your application to tolerate duplicate updates so you can use DUPS_OK_ACKNOWLEDGE, or explicitly acknowledge updates. Explicitly acknowledging updates usually yields the best performance if the application can tolerate not acknowledging each message individually.
Performance impact: Medium
To explicitly acknowledge an XLA update, you call acknowledge on the update message. Acknowledging a message implicitly acknowledges all previous messages. Typically, you receive and process multiple update messages between acknowledgements. If you are using the CLIENT_ACKNOWLEDGE mode and intend to reuse a durable subscription in the future, you should call acknowledge to reset the bookmark to the last-read position before exiting.
bÕ65TQ5U§SYµU]ÕU%@ `R " àVq5WuuWyµW}õW5X…uX‰µXuW W
À œõY¡5Z™uZ©µZ©õ °[`[¹µ[½õ[Á5\Åu\ɵ\Íõ\Ñ5]ÁõXU]Ýõ]á5^åu[³µ^íõ^±• ôu_ùµ_õ5_ý5`–_Ùµ`
ö` 6va¶aàa!6b%vb€V ;PK+9”s“P ŽP PK \8–A OEBPS/img/adminds2.gifïV©GIF87aÆ
ç ÷÷÷1J!!!)!!!!) !! B1ZcŒœœççïÖÞçÞÞÖ÷÷÷„„Œ )J)JcÆÖç„¥½k”µcµÞZÖRÖZ¥ÎBœÎB”ÆZŒR{¥Z{”s{Œss„{{{{ckŒckŒZZ”sc”{s”{kœ„sœŒ{””Œ”œŒ¥œ”¥¥”¥¥¥¥¥µµµ¥½½½½¥µ½µµ½½µÎ½½Î½ÎƽÎÖ½Ö¥½Î”Æ{”½RŒÆ9„½Z”ÆŒ½¥Œ½œ„½”kŒ¥k{kœsc”sRŒkRŒ{JŒŒB„Œ1sµBkœ!RŒ)1½ÆÖ½½ÆεµÖµµÖÆÆÖÖÖÆÞƽν)Rk1BR9BJBBJJ99R91RB9RJBRRRRZZZckRZkBZk9RcBZZJcRBZJBZB1R91B9)BBsss9ÆŒZÎïÎÎÎ BÖ÷1k¥RkŒRsœk{¥1ZŒ¥µÎRcœ9cŒ„”µ))) 1cŒkŒµ1B)B{”µs„”Z{Bs¥9k”J{! {Œ„)1B)9BZ!J!R)!J)!„JBŒc Z œs 9”„B9 ZœÖ„c 1 Œ¥J sZ Œ„k{sB„„k kkk9JZ „”„„9)ÎœœÎ¥Þ¥œZ9” sœµ¥{Z „sBc1B{1!cZµcZµsc½scÎscµssÆ”ŒsJJR”ŒZ¥„Z¥{cs{9 k9 c1 Œ”ŒR1 Zk{RRc{)!¥cZ½cRÆcJœŒk ck„œ{!RJµZJ½ZBÆZBs9 c9 RsŒs!œ1)B1½B1{RR½„„”ΔZR s{JJkµk{{cs”1)1!1!½1!{Œsœ¥Js„k9Bœ”½½½½RJÎZJ„B9½ssÆ{sÎ{sÖ{sJ1)Æ„{΄{Ö„{ŒZRÖ”ŒÞ”Œ !JÞÆÆÞœœ )Z !R, Æ
þ ðOÁƒ*\È°¡Ã‡#JœH±¢Å‹3jÜȱ£Ç CŠ I²¤É“(M.8П ÈœI³¦Í›8sêÜɳ'Î@ƒ
J´¨Ñ£H“*]Ê´©Ó§P£JJµªÕ«X³jÝÊ•©ƒ>m(ò¬Ù³hYšH˶۷Šx A€ •]J° $ˆß¿~ Â@¸0Bˆ#YÌ8±cÆ ‚L¹²å˘?hNĹ³çÏAˆ Mºti=zEYͺµëÖ‹ý™MûÏ Û¸oóÙ-¥·ïßÀƒ ïͨ¸ñãÈ“+ μ¹óçУKŸN½ºõë¿•kßν»÷äØÃþ3ç#e·ùóço×^ »}kÔ¦IƒžŸHóË =èÁ¿¿ÿÿ èß'ð£Ê ÈÊ‚ 6èàƒFè`‚^!†H\Ѓw $ˆ> &b‚V˜d(&fXŠ,¶è"ŠHH†YeöÑZ|8Ž†ZjŠôøڰɶžm¹é&^vß%ÉÈ‘L6éä“PF)…’TVÙ”L¢§ånê
ùG{±½§GŽ£Ùè™}”YðÈ~¶éæ€R˜`?tÖiçxæ©gr h!†‹ýÀ! û`Áˆ"
6˜‰‡¦"!Œ**餋2j饘šø¢Œ–Ù·™™ž‘)j=úä©`
9[nä]g¥wþXÆ*무†÷ê·Ö*Ý’¾-¹¥yƒð1ˆ—©Š)ªh r¦dj>@Å›5ˆp†1Ôs†5¸I ºtÛm>à‚«Ï¸ä–kî¹è¦«O¸àz«Ëa ºX$€}!
X‰™š8)‰A "°¾ˆRjðÁ+Ú¯¥-Òø)¨Ç‚À£©§)nîŠë•ºvìñDZn,òw /YÜ”¼šl²o¿¢7,{`{l²õÝ·X³>ä¬óÎ>ÔpFfUqF
<ïl>ܺûm¸ê6ít¹ìæ£ô»ñBv‡‚ Jð¾•^*©_‡
Èd—m6Ùb§öÚl·
ÈÖ\KºpŠ”= qÄ£îH1þk ÝÈ ƒ,øà„OøáÚéÊ+ÊI²Ü²°]Ö3kðÍLó²jZ°Ãæœw¾ƒ@ŸU…žwÞC%WÔ£z=ö´nÏ=°Ç.{ì&TkŒ ´ÛŽûì¼»Þúê«Ð#ïÍ9 7`™~ öÙ áüóÐÁüôÔWo½õn‡¯Üsø˜§4fš ®Ù â®þúê£ïþÉŠ«üjy-GN›{®ñå ¨ÙC
}´D`h àé® Âcu¾ãìŒÁ’ÛÝ£v”`ì|§:Â#xÃC‚Šw¼¿XêkX٢Ǻð…0Œ¡ô®GC³`üêWÃêæ©„j4þYUÆzõ¾í°ïˆH,YG+ùmŒq¿²ß—ðG9¼ Yý{DbHA€Z$ˆ1¨@Ôy0 hŒ‡<Ö(y¸ñoÄ å(ÛÁŽl\cãá@U2#„ñJè l*$› ÉÈF:†5¤žÚ¶6©…1
1HÄX#Dà,1qI ¥(CöIÀÍê“¿²ä”¿X1W¤ÿ¸8c8ϵ|áé¬àAxì‘w¼# ÐÅ:– ˜oÌã =¨
J„0ƒQf@ÍjZ³šh€ ±)2z}çÆIÎršóáL§:×ÉÎv²ó‘ð|^$™ç6BÆQ™þäŒh8y›à”<£ ¨@ÅóÏ‘²”©\%+)§¿ýÅ4³„ázà€:ã–¹tá.{ùË5"ŽÃã1?:e¦‘™Î$ GÔ€:¸ô¥0õÏK%pˆo>/?ØJÇSÏó§@%§;‡ÏEÎS’ÙÓ òC Âü bA‘3ЪZUcSÍ–²Zœ-Áì5
Ý ,!ªÅ"bZÅ@p†Œ¶
ï°B.ráÀ[Øõ¸È«^÷Ê×#€¬1JÀ×Âîõ®ˆÍE3Ÿ¹RÉ .éfó 'Ní²˜Í,Ï8—3ÎõœCíCQexTì±íž“Ñ'T³Û ‰«‹»þªlgKDØVi«°ÕÒËî·Ð*¾’¬;˜dQŒ3œ 2À0SƒY¨âÐ.tÛA]eXWîÈ®v·{\ÊÄ'pv·›ÝëZ—ºínt·± Æ
Q-ôjà @à¾è Yèu °Ö± )höÀEƒÁ& `N\Ö³A
' à @“œáÈ!ˆr” ]ŒãXÎr9¶¼esxùË`þò7¼ë c|#Ìhö2þ—·œå,çÂî&` {O-,/Íï~»ÉÂ>üÀR ‚Y;Á:
ª&ì tbØ膇ð¼iØÄ@…š‹K;oŒž¬:0 =xbÓª§gâUWïm,>Œ‹W c©Â¶Æ¸ží·UÆeÕe
ý±‘Å™!çáØÈF²‘Éì 8¹Ê62•Üf,o™ ØNs˜Ç\3kûËØ&—«}7Ǿ Baó Ì$=pN?ZЄÎ7Ï ïœ™sÂF§¤/!…A¾@èD&Héæ½þÄa‹LÁy×k5
†OÕòŸµq®þG^Õ]Ã
·ÄÉ-°V ¤°ŠÕ… ²g mcÜ#°´£]äi_¹Ú×Îö·ÍÁm›xûÛá wµÍÒ÷Žè±@8/œ@u^´;° è/æ]ï?:g“ö&2q »À °s† ƒ=ÃŒÆ7¿uÖvµç Ð Ž»95±p¡öAá˜4ô@
↠qÅIýÂN ãeF#Ô~R0xšÙ2/ùtLžÑ©}êÇc,ã‚’üô5ùÉ¥dr`÷øGŠöa.ó™ »æ77Ï‘ìsr‹[Üåú˜o›çþÌß^39ÈÍtÈ@ÝxÕÀ‹^< ï¶ 8¸þNY{ÝaoûÙl‡!ø`Ñn»ƒ< ÃÀ7h…Ü7qh±Ûaý›0¿%íöû œÓh~jD xÏó
—i›–i–i¥Àa0D
—f6’·i§qy›'A yáÀhù$¬µ~Sz¦‡z*xDª—>Q¢zéÁr@{VD{¶—lH6-Ôòd»'mUösm|]¦mÃw|Æw_G—f\†mÌgM'gAgUÇ Õ7×lÜÀ}7å}ø~÷wwg~—09ð~:hh~ûF9ã~kç÷f æn (€êD€è<hy`Á°€1”wC°þe3
¥€¨Èø6‡Ð
Œ0k¬e¶f[+¸‰íÓ‚F„[&G?\òz-‡76˜=XdG¨{©X
@à
º@n×€
´H‹Ùp‹¸ˆ‹GX|ß
Eˆ„¹˜‹µX‹ä¶
Nè|5g pÔW}½`}åRõ%|Ö}^×…c(v™w÷u“†a w‹6‡:3wàÈ`vo;pwhayhD€€˜Æ‡‰§€Ícj›6ˆ$ÆBg#RÐ ÂŽ‹Øˆ ¸ ØC ‰¦À –Xk(8Uœ‘ƒã‰ Äz-(ŠÂÂ[Cƒ¢B{e«(e"9’! Ö
Y6ŒÃŒÁ¨
¶£
¸èþ’Õ“,y‹*9ŒXÆ^çöt ð TØ ¾à IÐn,XÕ¸…×øvæ7v܇Þ8†aW4îÇ9cŽÙÈ3÷6NYIN€·N iò8xvðx†‹ ×BÔ
™ðÂàjdCš÷ˆ™$²
¹'˜rš(‘~é1¹ Šô9T{ 5@’Œ!I’Í™’ Îð\ê%]Ð
š
ÒЙžù™ š¡¹™Ñ
—]ºÐ^Oˆn> ”¾ð Cuà ØGé<âtoJ©M©›“V‡˜Å”UɆtø~øæo[Ù x(a§–N@€€öpó(ˆ X–‹‡Ðs=£þ`q¡°ˆgÓˆÞ Ø H@ •¨Z—¸—¾vkùžM˜T5˜»Ö+7½UŠ8Ò]PHP{ ÅP-Å0 º{°@p ª€ È@ J µP¡Ép¡æ•¡º¡ j]z¡Z *¡ª ;éX PÎ3ä”͆_µy›î˜”b¸”ÛØ‚v‹¦†–À ñ'hš@Žsw~姕DðÊi‡Hhë´höœ ЀÒé<—–@ ˆdÓi¨Ö ²@f3
]
qA
¡vbzhy‡hyŒ¨Ðw¦pi.ÆZQàZ)rðÙ§/(ŸÇAJY˜þ»u˜°çr¢á`Q'\Žj}0 «0¡j ¶€XweXšº©‡…©wU¡s¥ s° 'ªŒØgX2a›ôVoºY£¼‰£°J¤jçx£ÃÉ å´hµúwLê«-djF¥'6¬Îó‡gJ6fŠb‰ˆŽsiy æP§åyW
§À§i`P@êÉOžTŸ~Z®9¨Æa‘iŸ£ˆŸù)l¥q; CÓo„–
XÐ'«°¯û*!þú¯ ¯ûš «
$@ ; «É“¥…HùöªY›óYGT£Å)FOIµ±aã ±ÖTᚧìÙž\e®(Û$èš®P²þ²¢X¨ï
¯£ŠÚ…p³8›³…ð<Û³> @´B ’P´F{´“´J»´LÛ´Nû´JK G+ “P =p•ñ|#‚ˆÐµ^ûµ" ¶"€cÓgâ±K±¡ÕN«–›Tö· «-6²Q r{š‚)»·Ø±²ðs®òÉ®©‘³@‡à=`ŒÛ¸Žû¸¹’;¹”[¹–[¹
›µÉhBL…"þ"Þ´[ègk[ºëÔ¶tT§·KeI˜B ‹yI²Â¡z|{»Õá·±å$è*¸†éc…k¸e#hò¨Ñ"®›¼–dZ{<†(¡kS¨;½ò4O7þ´=]“¼›²½,ò0£§z:®¶‹»äû º»»L¢cëJ¨2¼ )* ²,Æ{¼)¢¼ö‹)šëtpc)#’HfC½û¶×;"Ù«).ò=à>
œ,ß‹§wKzÖQJå;Áçã·²¸/»[S¼Âk9Ä+¿ó‹¼÷;Â붰“)Ðë¿[ZÙƒ½˜B7¼Àš${4\¥âxÛ²¦DÁ<,¾€zÁÌ%¿ËÁ«¡ˆjñ ÂÆë"$LÂ&Œ( C0lƒ6 «TÇ£0—²CHàTô7¤R*` ƪ±7D\ÆA”à c%=¼Æ&»¾êº¾À³f|ÄHl&Jü¨LÜÄö;ŒÑ¼#âºþ±· C)–¤Å[ÌÀ8òÅ7lÆŒì%ŽüÈ«‚1¸zlÌÆ.+¨p 90 ¼ lÄ L ÅÂ,¢ÇÊËÇ‹áÇœKÊ,k®»C˜dÊŒa7]L&`lÆ\$¸œËÁ²%*H2•üËm<¾ôé‰ìŠ=ÆÉÁKÇ¥aÇwì¨yLÊ ƒŒú{ÂÐܹÞ㨲l#¢¢7dü#ªÉ£%¿ìËÀlÉ?ŒÉé8ÆLŠ,V <¿‹Q¿Õìº}¼¹A°¸–û&ú¼Ïü KhikN¦{º \кРРÝÐýÐ Ñi«Ðl{ÐKÑN½HìtN–õÏÖÏ"=Ò$ >`§¼þ¹= ÐÒ.ýÒ0 Ó2=Ó4]Ó6}Ó8Ó:½Ó<ÝÓ>ýÓ@ ÔB=ÔD]ÔF}ÔHÔJ-Ó:ÛÔNýÔMmR=ÕT]ÕV}ÕXÕZ½Õ\ÝÕ^ýÕ` ÖT'O¨lXj½ÖlÝÖnýÖp ×r=×t]×v}×x×z½×|Ý×~ý×€ Ø‚=Ø„]؆}؈؊=؆Є B›‹Ö‹]Ù–}Ù˜Ùš½ÙœÝÙžýÙ Ú¢mØýØ)=ÍA@Ù£½Ú¬ÝÚ®ýÚ° Û²=Û´]ÛPÚ‡qÚr†ªmÛ¾ýÛÀ ÜÂ=ÜÄ]ÜƽָÛgÖÇÝÜÎýÜÐ ÝÒþ=ÝÄ]ÚÙËMÝÚ½ÝÜÝÝÞýÝàíÖÖÍÇÙ Þæ}ÞèÞê½Þ—Û‰áǼÍÜì=ßô]ßö}ßèÝØ×Z[½½Ösà>à^à~àžà
¾àŽßþà áÑ=Þ‡ñ|†ñßj=
»á Þáh1 â">â$ÎÚÉ
)Ðd" Xîá.þâpÁà2>ã4^ã6~ã8žã:¾ã<Þã>þã@ äB>äD^äFÎã¶Ü„‘â.ß ãP åfÑâR^åVîâ~åZ¾å\>åTÞå` æ åb^æmAæfîhžæjžäŽmLîßNžálnæ ~ßc®á%>×þy ÞçÚ
è -è¡=ænn"qN+X_^ç]~çöMè{þÖ’^ß•Ý—¾Ù™ÎÙ†^ÛJŽ‰ ßnÝèŽvPåáÈånéY>éq½éë
ëÇ-ë—Më˜Ýé´ý顾è@êqê,ìi!ìlAì ìÆã«N߶¾çÍnÞÏ.ÜÑžØӮظ>Ûº^<*>ç,ŽÉžìÁþÆŽìV>5aêvà é ç `ìþî:±îðÞç7Á`ð~ï2!ï4aïøÞïêŽïô¾ï6±îú>áˆüîï÷^ðaðŸïõžïoð?ðîþî ¿Oñ¯ð>±ñê^ñÿï!ßþñ`/Ë ÛÙ.HÛ>êÞnÂÎ`¿`5oóeîvó3ì<Ÿæžò ?ðBïñ<1ò
ŸåDÿðFôKñMïôþò(Ÿò _ðW_ôQð
OõPî_ÿõXÿô$ H^¯õ[_iÏô#Ÿîc öòžñ×.Û-ï /ßÖ¾îó9ÿëáÎ÷Äþí8_ê~OøÇNî†?å`ïq¯ökÏôýÞöÿøZŸõ”Oö÷îõúNð˜ßø“ùaŸùJoõXÏù‹ïùeÿù;qö7!ù©úõ5úª÷\ ÷–O÷+ÛwŸ÷l½÷ß^ê4Ï÷‡¿óÞÞóÂø‰ü,ôªOò´þ_ò'ïø'?÷!ÿðU?ýûîîÚÏñÔý3áúí~ýp¿ù ÿü úÙ/þÕñÞŸð%?þÏÿþÖÏðšoõ˜ÿÜ?ÿúŸÿù¿ýØÏþ aÇÁ@‚ æÌ@p @vt¸P¡Ä† Rœ¸ÐáÅ F„¸1£A„3†Y1%ÅŽ+N$™PáE‰4Yž|9£Bƒ|þTèP¢E5ÔÃÒ¥ rÀt©… DÀš€ X¹nÕúUlØ®eÇ‚Ízvkǯeç@€ — ¹réB¸‹·n\½|ãæíëp¯àÀ|ï¦{xï`Å|# Œà°dÃvWÆÛø2f¿}þ.üw±Þƈ-{†ûxNdÌy5&Üy²hÚ„—n]wí×T³®í9ñhÆ ew ý:ñnâ¿eÇNnyòpÞÈsÞLÙîôã¨ã>>^üøñI 1%äªT T–õj6~ÚùmÑÒ'‹Ö¾Zûð±¾Å.8â¼›-:áSn@æBóî:Ú¶3еaÛˆ¸QÓ,à µKð@Ç Ó.´ O ðA5ÄPÁìNôËÁË$ìA ‘ÛζîdœÌEÉ$ÐCÓ¼ûD
+ ÈØf‹Ñ·ÕÈc²IòÌ;ƒôžŠJ*÷†ºJ¾üîÓo>/¿ì’Kþ¶ì
@{ÌŒÇ3MD‘ǹTÄÁ…\þó6ã|dKN4ÜÅ4‰DrEƒ\-DÒŠ4”Ï}äíÎ@ãôPà6£.ÆÞ¸CîÇGËóÃBi,ÐíÕ::Ý´»G ÏIW_*)) ¡U½*™ºR¨,»š‹×ÂìˆËµ~Å/Ø/…ÏÌ"“¼ô8M{dVÕ>s<ÕÈe÷ÔsEkŸÍ.Z§óS6eœ±DêºÕ³ÀUÁõtRßý6À@¹å,IIõ¶.5KLÚ 7ÅÔ´$[…µ`WeuÊõ¬¬
Kÿ †8b‰'¦Ø DÑÕvQzÛÌM´íW\6;t³co„´dA£û8ÛÝÎÒ‹éõSå•[Žôåxwf“ãþ´¹Awz\Euü÷FLå“`ƒŸ.O©¥j¥’½\ƒÚµb·æÚ¿9² l;Â&{ì,ÌÛ¡²ÉN[í°;z;î³å>{£²í{î¶Ñæ›íßØÞ[ïºÝœo¼ |lÅOünÂû.üíÃÏÛðÇéûïµÙ6{®½Ñæ|r¸ó& rʯ\òËI[s¹Mïœ-Ç'Ÿ½öØ݆ö,\WðÓAGüwÆw‡Œóáç^vÛ?7Ûi¨ŸGª‡(¥´Õê†uí:{í¹þzxï¿?|ñÇ'ÿ{ÞËG?}õ×g üóÛ‡?~ùý.~~ûï'~5üÙ|àçw ô„1¥z {Ïöþ¸@¯íÏ4_ý 8A
¶¯Ä`ü.˜A nƒ™“ úþ'¿ p€lJÕè0¶°…Ýû` ×çAÖÐ4´aɆC ’0„:ä!KhBè¡ÄÕõ°æB&*†=„"ýôE*ð‡U„b±ˆ>-R°‹ "¡fD$NE‰@ÉZÕH±9ÔÁo„c å8G:ÖÑŽwÄc ñø=öÑd 9G>Ò‡Dd ™HF6ò‹td !II.IŒ&$£
“˜À5vrbe(E9JR–Ò”§De*U¹JV¶Ò•¯„e,e9KZÖÒ–·Äe.u¹K^öÒ—¿De&þ¶IzÒ˜ÇDf2•¹Lf6әτf4¥9MjzR˜·2#'/¹MnvÓ›ßg8Å9Nr–ÓœçDg:ÅxMëiSï„g<å9OzÖÓž÷Äg>Ç(5j2›ÅÔg@:P‚Ô EhB÷Éž2¶çŒ?É’B%:QŠVÔ¢ÅhFƒÂÎb+iHE:R’–Ô¤áá(1=
€“¶Ô¥/…iLeJÎk!*]âGgºSžöÔ§?•iMmúÏ•Õ¨GEjR•ŠO¡âYYjT¥:UªVÕ`B êÕžªS«vÕ«_ëQ±JÔœ²4¬gEkZ՚Ѧ’u«f]k\å:WºÊ«6Õ*D¡ZþW¾öÕ¯=!?S›6¯>‰(`»XÆ6–€‚="•
‹×‡"v¯ŽÅlf5‹Ö»á°¹ìfE;ZÒŠ²¶š¬g+ Z®–Öµ¯…I;ûÙÄÆÖ¶·ÅDg»ÚÚæÖ·¿.= xˆC v²´
mp•»\æ~aÄ-®dËÛä6׺×Å.¬†]ÂN×ÙoxÅK”í×°ÔmíxÕ»^ëÊ
ºÜu@j‘›^öÖ×¾¸MÊ{á+_ôÂõ¾ÿpió{ˆÂš—²ß
p‚Üؤ¤ÖV€ Äy¼`
W˜®
ž¬. áÔ qZ1\`*]ÀÄž¯C¼bKuÄ6Õð‰‘âþ×ØÆH5„ \â_€Æ7rƒªã óøÄ?r’•<Ò Â1>r— ‰&€* ç„Î_éŒ5Qoþ°!MÒ(ÍÒvpú:úBàú€ðÔ„ûº¯Å.›ÊNü”°z Ÿ
¥0mÙ°Ì´0Úúîï¯õÂìLÜO
g •ññ"¯ÞÜpßà0pà ®ñ0ôŠ€&âöÐúðã@. FÎÍñ _Ñr@`Nð ŒéQrÃÉð1 õq [l5LÅ qC”C•J [ƒ YÌ r!r8ò!!2"%RÇ$@ C) `#9²#=ò#A2$Er$I²$Mò$Q2%Uò#€ \’
À à h²&mò&e2'ur'u|Ò' (…r(‰²(aò(‘2)•r)™²)ò)’#`*©²*ò*§’#¡r+¹²+½ò+ƒò'År,ÉÒ' à,Ñ2-Õò,Ír-Ýò-Ó+år.é².íò.ñ2/õr* /ýò/30 # ;PK/Á_'6N 1N PK \8–A OEBPS/img/jdbc_steps.gifrN±GIF89a ÷ þþþ¾¾¾€€€@@@ÀÀÀ÷÷÷øøøúúúüüüòòòêêêôôôïïïûûûõõõöööùùùÂÂÂñññBBBóóóÃÃÃýýýðððÕÕÕ²²²»»»âââããã666îîî‚‚‚ìììDDDèèèÛÛÛæææ½½½···žžž ===àààßßßÅÅÅuuu‹‹‹~~~777ÙÙÙƒƒƒ±±±ÚÚÚÝÝÝéé饥¥JJJFFFÔÔÔÞÞÞäääÄÄÄÆÆÆ
;;;ÊÊÊ555}}}>>>ÏÏÏ¿¿¿ÇÇÇrrråååÉÉÉÈÈÈÒÒÒ………???|||ááᣣ£ ÜÜÜ„„„‡‡‡µµµ ÍÍ͆††ŒŒŒ××׫««ŠŠŠ¹¹¹fffíííkkk$$$ØØؼ¼¼°°°zzzwwwëëëÑÑÑvvv–––lll222ççç ¶¶¶<<< •••³³³ÁÁÁ‘‘‘xxx ,,,ÖÖÖ´´´ŸŸŸpppeeegggCCC333’’’```\\\YYYNNNHHH111TTT888”””˜˜˜AAAddd"""___999sss)))::: iiitttqqq[[[ˆˆˆÎÎÎKKKËË˺ºº]]]
›››jjjEEEÓÓÓyyy'''¦¦¦nnn¬¬¬¤¤¤!!!¯¯¯aaaOOO(((...GGGšššªªª™™™LLL000XXXbbbœœœÐÐЉ‰‰SSS¡¡¡+++oooPPP¢¢¢{{{ ###¸¸¸ccc444***VVV&&&---“““———mmm®®®QQQhhh^^^ MMMRRRUUU©©©ZZZWWW§§§IIIÌÌÌŽŽŽ%%%¨¨¨/// ÿÿÿ!ù , ÿ ý H° Áƒþ \È°aA…#.„(±¢CŠ3 Ĩ±£@Ž '† rdÅ’& ¢LÙp%K‘/7zœ ¦Í›8sæ,¤³§ÏŸ>y
T(Ñ£G"]”©ÓžJŸ•JµfÔªK¯bÅ©uëЮ^‚õ:¶§ÀÒª]˶۷pãÊK·®Ý»xóêÝË·¯ß¿€ L¸°áÃrÏþ[̸±ãÇ#KžL¹²å˘3kÞ̹³çÏ C‹ Mº´éÓ¨SSV¬ºµë×°cËžM»¶íÛ¸Q³ÎÍ»·ïßÀƒ N<õîâÈ“+_μ¹óå<ŸN½ºõëر'´“½»÷ïàËÿ÷L€Ù‡ñèÓ«_Ͼ83ÚËŸO¿¾ýÎÇïëßÏ¿?øüþ(à€ú`&¨à‚ ÈàƒŽö‚/pv‚üÃ@„Â9ÈᇠRvŒ:2 Ã3ÅdÖ# Љ ”µPC y|ðÁ/DìN R„8š‡>É`4Œ±,>ÐAÄ‘‘”‰Ë.$p 2HfäktÀd! ð Ù`™f¦ùà ³,&ÿ”?d0f„?D81Ù›ÿÔàÏ ‹%ÐJd|þS€@‹Ý€ ©æf@>*é}‡ìb Müá<” c¤n<MœØ³Ø4šR0?» ÿ£j ‹!pJ3Ô˜Àê¦Ó êÏ?X„ðOÆ÷)• 1
ÿàʳ<É4“.iµØ²×Š?,0 @ `ƒhcg @Œ@pÏ 'ü¸#Ð I0û t80' €¯ 0cl±ÿÈHÉ?¢’7] ¶×fkñx‡`í¯1ŒË˜@1üÓh–d~±qÐÀã$ÉüÓ3Ú„ Ž?|Œë+d)r™OÌFþLñ þX`AÐÙV|ñÒÞe|ò
…ÁØ 1Kp£HœÌÏ?<ÀÇ Ìü³„?‘ 0ýþj(¢È³Áÿ\ó
ý£ƒ?•TâI;ÿÊôßèˆÿ Ú #þ„¼˜3þ0rÁÎ5üôÖ…ÿÚÉ‹@E9ÀúÓ…ÿ P¢Ô¬6‹}àÏy`´#FÍ,FHDá@ßÆ®{xøø3„°øsH0Òÿ01Dºoû“ÎÊd‚ú?Á r ¼üS üsâÂhñËÕOÀ¸ãÏ9ÿ¬â|.þp?ž!D*Sì÷îüc—€/¦¨Ã? aˆÐ
J EH¡0¦QT°C
8À¾€ 0BD@‹Ûý…0…%*0Àº`¾ðE0° ¤À)À@ 1ˆ `?²‘
"¬
úË]rÿF‘ 1 .˜L ,ó‚Q”†YPâe°P§ c Ë)@$3Š
1¦‰r€¹Oe€ £º€pŒ @?•€4®±V8Àp8ÀXc þè€ \ ·3€ m°S˜¢ ªÐÙ¤”Æ›Õéâ’‰Xd ðË ª4APÃ&;i™dôè 4Ñ ØYtâløl xÈ¡
iB ³kÀ#–ÿ¨B â€ËÆ !’ñGóÉl©}¹91Ö°†c4£]Õ¢dnüBvÀ /€Ã†â„
1NœŒ)Á ‚i䯙°ÁÂÅÀá¾ #ÿOä¯17 Ì tÏœþ@§¡DÀ Çà@ë('¤
ƒ2¦…Ð'd"@€@PAnB
p€@bfl̲!Ç< ’B †Å
n¤ô pðG0rÏyÖ³pO`ƒpÙÌÅ`T£BÂÀt±…ŸÚ¦ @
n0Îlî¯8EcL¿Ö` dþ-ó•2ƒ
The NLS Connection Attributes for GlobalDSN are set as follows: The Oracle TimesTen Logical Server Name Setup dialog box contains the following fields and values: The following buttons appear on the right side of the dialog box, from top to bottom: OK, Cancel, Help. The instructions at the top of the Data Store tab of the TimesTen ODBC Setup dialog box are: "Choose data source name, database path+name, and other desired options. To use default attribute values, click OK. Otherwise, modify attribute values on all tabs and then click OK." The Data Store tab has the following fields: Data Source Name, Description, Data Store Path +, Log Directory, Database Character Set (drop-down list), Type Mode (drop-down list). In the Data Store Attributes section, you can select Temporary. The following buttons appear from left to right at the bottom of the dialog box: OK, Cancel, Default, Help. This graphic shows how an application can access the TimesTen database engine through one of several methods: Use the ODBC driver to the SQL or PL/SQL engine. For Java programs, use JDBC to access the ODBC driver. For C++ programs, use ttClasses to access the ODBC driver. Pro*C programs access ODBC driver through the OCI interface. ODP.NET programs access ODBC driver through the OCI interface. The OCI interface accesses the ODBC driver. These are the steps and the tools shown in the image: Repeat steps beginning with "Set various optimizer hints" until plan is fully optimized. The First Connection Attributes for TempDS are set as follows: The following attributes are checked: These are the steps and the tools shown in the image: The Server tab of the TimesTen ODBC Setup contains the following fields: Maximum Connections Per Server Process, Server Processes Per DSN, Server Stack Size (KB). The following buttons appear in a row at the bottom of the dialog box: OK, Cancel, Default, Help. These are the steps and the tools shown in the image: This graphic shows how the TimesTen Client links with the ODBC driver. Then, the client connects over the network to the TimesTen Server, which links with the Data Manager ODBC driver. The Data Manager ODBC driver is the interface for the TimesTen database. The instructions at the top of the Data Store tab of the TimesTen ODBC Setup dialog box are: "Choose data source name, data store path+name, and other desired options. To use default attribute values, click OK. Otherwise, modify attribute values on all tabs and then click OK." The fields are completed as follows: The following Data Store Attributes are checked: Temporary, Authenticate TimesTen Client Connection. The following buttons appear at the bottom of the dialog box: OK, Cancel, Default, Help. The PL/SQL ODBC setup page enables you to enable PL/SQL, and to set the PL/SQL first connection attributes that include memory address and size. You can also set PL/SQL connection level attributes for PLScope setting, the PL/SQL connection memory limit in megabytes, the PL/SQL optimization level, the PL/SQL timeout in seconds, and the PL/SQL CCFlags. The following buttons appear at the bottom of the dialog box: OK, Cancel, Default, Help. The Data Store tab of the TimesTen ODBC Setup dialog box has the following settings: Authenticate TimesTen Client Connection is checked. The Cache Connect tab of the TimesTen ODBC Setup dialog box has Connection Level Attributes on the left and Data Store Level Attributes on the right. The Connection Level Attributes are: Oracle User ID, Oracle Password, PassThrough (drop-down list in which 0-None is chosen), RAC Callback (check-box containing a check). The Data Store Level Attributes include a field for Oracle Net Service Name. There is a box below RAC Callback that is labelled Dynamic Load. The box contains a checkbox for Disable and a drop-down list for Error Mode, which is set to 0 - Errors not shown. There is a box below Oracle Net Service Name that is labelled Cache Grid. The box contains a checkbox for Enable and a field for Message Wait (secs). The Message Wait field is set to 60 and is grayed out. The following buttons appear at the bottom of the dialog box: OK, Cancel, Default, Help. The steps and the tools shown in the image are as follows: Repeat steps beginning with "Set various optimizer hints" until plan is fully optimized. Additional information is in the text preceding the figure. The Create New Data Source dialog box displays the following instructions: "Select a driver for which you want to set up a data source." A scrollable window appears below the instructions. Several drivers are listed. TimesTen Client 11.2.2 is highlighted. The following buttons appear below the window: Back, Finish, Cancel. The NLS Connection Attributes tab of the TimesTen ODBC Setup contains the following drop-down lists and their values: Below the drop-down lists there is a check-box for NLS_NCHAR_CONV_EXCP. The following buttons appear at the bottom of the dialog box: OK, Cancel, Default, Help. The Oracle TimesTen Client DSN Setup dialog box contains the following fields: A Refresh button appears to the right of theFailover Server DSN fielfield. The following buttons appear on the right side of the dialog box: OK, Cancel, Help, Servers. The following buttons appear at the bottom: Test Oracle TimesTen Server Connection, Test Data Source Connection. The NLS Connection Attributes for AdminDSN are set as follows: The Data Store tab has the following settings: Authenticate timesTen Client Connection is checked. This graphic demonstrates that the client application refers to the Client DSN to initiate a connection. The Client DSN contains information about the server machine and the Server DSN to locate the TimesTen database. This may or may not include a logical server name. This graphic shows several detail tables in the database. A materialized view is created by taking certain rows from each of the detail tables; thus, enabling only the desired information to be shown when a select is performed on the materialized view. However, all updates are applied solely to the detail tables and then reflected in the materialized view. The General Connection Attributes tab of the TimesTen ODBC Setup dialog box has a column of check-boxes on the left: DS-Level Locking, Durable Commits, Wait for Connect (checked), Private Commands, Match Log Opts. These fields are on the right side: UserID, PWD Crypt. Below the fields is the Diagnostics field. "1" appears in Diagnostics. These drop-down lists are on the left below the check-boxes: DDL Commit Behavior and Isolation. DDL Commit Behavior is set to 0 - Implicit Commit. Below the drop-down lists are the following fields: Query Threshold (secs), Query Timeout (secs), Lock Wait (secs.#), Replication Track, DDL Replication Level and DDL Replication Action. "10.0" appears in Lock Wait. The Low Memory Warning Thresholds section is on the lower right side. It contains two fields: Permanent Data (%) and Temporary Data (%). The following buttons appear at the bottom of the dialog box: OK, Cancel, Default, Help. TimesTen supports transactions that provide atomic, consistent, isolated and durable (ACID) access to data. TimesTen transactions support ANSI Serializable and ANSI Read Committed levels of isolation. ANSI Serializable isolation is the most stringent transaction isolation level. ANSI Read Committed allows greater concurrency. Read Committed is the default and is an appropriate isolation level for most applications. Applications configure the transaction features they need with connection attributes or connection options. See "Connection Attributes" in Oracle TimesTen In-Memory Database Reference for more details on how to set isolation levels and durability options. The main topics in this chapter are: All operations on a TimesTen database, even those that do not modify or access application data, are executed within a transaction. When running an operation and there is no outstanding transaction, one is started automatically on behalf of the application. Transactions are completed by an explicit or implicit commit or rollback. When completed, resources that were acquired or opened by the transaction are released and freed, such as locks and cursors. Use the following SQL statements to commit or rollback your transaction: The SQL The SQL Note: Read-only transactions do not require a commit. When executing write operations, complete transactions to release locks. When possible, keep write transactions short in duration. Any long-running transactions can reduce concurrency and decrease throughput because locks are held for a longer period of time, which blocks concurrent transactions. Also, long-running transactions can prevent transaction log files from being purged, causing these files to accumulate on disk. A connection can have only one outstanding transaction at any time and cannot be explicitly closed if it has an open transaction. The following sections describe how you can configure whether the application enables implicit commit behavior or requires explicit commit behavior for DML or DDL statements: Autocommit configures whether TimesTen issues an implicit commit after DML or DDL statements. By default, autocommit is enabled, following the ODBC and JDBC specifications. When autocommit is on, the following behavior occurs: An implicit commit is issued immediately after a statement executes successfully. An implicit rollback is issued immediately after a statement execution fails, such as a primary key violation. If the statement generates a result set that opens a cursor, the automatic commit is not issued until that cursor and any other open cursors in the transaction have been explicitly closed. Any statements executed while a cursor is open is not committed until all cursors have been closed. Fetching all rows of a result set does not automatically close its cursor. After the result set has been processed, its cursor must be explicitly closed if using the read committed isolation level or the transaction must be explicitly committed or rolled back if using Serializable isolation level. Note: If you are using ODBC or JDBC batch operations to Commits can be costly for performance and intrusive if they are implicitly executed after every statement. TimesTen recommends you disable autocommit so that all commits are intentional. Disabling autocommit provides control over transactional boundaries, enables multiple statements to be executed within a single transaction, and improves performance, since there is no implicit commit after every statement. If autocommit is disabled, transactions must be explicitly completed with a commit or rollback after any of the following: Completing all the work that was to be done in the transaction. Issuing a transaction-consistent (blocking) checkpoint request. Updating column and table statistics to be used by the query optimizer. Calling a TimesTen built-in procedure that does not generate a result set in order for the new setting specified in the procedure to take effect, such as the You must establish a connection to a database before changing the autocommit setting. To disable autocommit, perform one of the following: Traditionally, in TimesTen databases, DDL statements are executed as part of the current transaction and are committed or rolled back along with the rest of the transaction. However, the default behavior for the Oracle database is that it issues an implicit For the TimesTen release 11.2.1, you can configure for either behavior with the 0 - Oracle database behavior. An implicit transaction commit is performed before the execution of each DDL statement and a durable commit is performed after the execution of each DDL statement. This is the default. 1 - Traditional TimesTen behavior. Execution of DDL statements does not trigger implicit transaction commits. DDL statements include the following: The consequences of setting DDL changes cannot be rolled back. DDL statements delete records from global temporary tables unless the tables were created with the Tables created with the For more information, see "DDLCommitBehavior" in the Oracle TimesTen In-Memory Database Reference. Both autocommit and Autocommit applies to both DDL and DML statements. Enabling for implicit commits of DDL statements overlaps in both options. If autocommit is enabled and To enable Table 8-1 shows what behavior occurs when you enable or disable one option in conjunction with the other: Table 8-1 Relationship between autocommit and DDLCommitBehavior ON ON All statements are automatically committed, unless you have an open cursor. DDL statements are implicitly committed before and after execution. OFF ON Recommended setting. DDL statements are implicitly committed before and after execution. All other statements require an explicit commit. ON OFF All statements are implicitly committed after execution, unless you have an open cursor. A commit is issued after the DDL is processed and not before. OFF OFF All statements require an explicit commit, including DDL statements. Logging and locking are used to ensure atomicity, consistency, isolation and durability (ACID) semantics for transactions. Locking and transaction logs are used to ensure ACID semantics as a transaction modifies data in a database as follows: Locking: TimesTen acquires locks on data items that the transaction writes and, depending on the transaction isolation level, data items that the transaction reads. See "Concurrency control through isolation and locking". Transaction log: Modifications to the database are recorded in a transaction log. See "Transaction logging". The following table shows how TimesTen uses locks and transaction logs: Locks that were acquired on behalf of the transaction are released and the corresponding data becomes available to other transactions to read and modify. All open cursors in the transaction are automatically closed. Locks that were acquired on behalf of the transaction are released. All open cursors in the transaction are automatically closed. TimesTen supports temporary databases, which have essentially no checkpoints. However, they do have a transaction log so that transactions can be rolled back. Recovery is never performed for such databases. They will be destroyed after a database or application shuts down or fails. For information on temporary databases, see "Database overview". All TimesTen transactions are atomic. Either all or none of the effects of the transaction are applied to the database. Atomicity is implemented by using the transaction log to undo the effects of a transaction if it is rolled back. Rollback can be caused explicitly by the application or during database recovery because the transaction was not committed at the time of failure. The TimesTen Data Manager provides durability with a combination of checkpointing and transaction logging. A checkpoint operation writes the current in-memory database image to a checkpoint file on disk, which has the effect of making all transactions that have been committed at the time of the checkpoint operation durable. All transactions are logged to an in-memory transaction log buffer, which is written to disk in one of the following ways: Guaranteed durability through a durable (synchronous) commit Delayed durability through a non-durable (asynchronous) commit: Note: The following sections describe durability options for TimesTen applications: Durability is implemented with a combination of checkpointing and logging. Checkpoint files: A checkpoint operation writes the current database image to a checkpoint file on disk, which has the effect of making all transactions that committed before the checkpoint durable. Transaction log files: For transactions that committed after the last checkpoint, TimesTen uses conventional logging techniques to make them durable. As each transaction progresses, it records its database modifications in an in-memory transaction log. At commit time, the relevant portion of the transaction log is flushed to disk. This log flush operation makes that transaction, and all previously-committed transactions, durable. Control returns to the application after the transaction log data has been durably written to disk. A durably committed transaction will not be lost even in the event of a system failure. To enable guaranteed durability, applications set the Any recovery uses the last checkpoint image together with the transaction log to reconstruct the latest transaction-consistent state of the database. Note: If most of your transactions commit durably, you may want to set the In delayed durability mode, as in guaranteed durability mode, each transaction enters records into the in-memory transaction log as it makes modifications to the database. However, when a transaction commits in delayed durability mode, it does not wait for the transaction log to be posted to disk before returning control to the application. Thus, a non-durable transaction may be lost in the event of a database failure. However, they execute considerably faster than durable transactions. Eventually, transactions are flushed to disk by the database's subdaemon process or when the in-memory log buffer is full. Applications request delayed durability mode by setting the Applications that wish to take advantage of the performance benefits of delayed durability mode, but can only tolerate the loss of a small number of transactions, can perform periodic durable commits in a background process. Only those transactions that committed non-durably after the last durable commit are vulnerable to loss in the event of a system failure. The performance cost for durable commits can be reduced with a group commit of multiple concurrently executing transactions. Many threads executing at the same time, if they are short transactions, may commit at almost the same time. Then, a single disk write commits a group of concurrent transactions durably. Group commit does not improve the response time of any given commit operation, as each durable commit must wait for a disk write to complete, but it can significantly improve the throughput of a series of concurrent transactions. When durable commits are used frequently, TimesTen can support more connections than there are CPUs, as long as transactions are short. Each connection spends more time waiting to commit than it spends using the CPU. Alternatively, applications that perform infrequent durable commits cause each connection to be very CPU-intensive for the TimesTen portion of its workload. Applications that do not require optimal response time and can tolerate some transaction loss may elect to perform periodic durable commits. This maintains a smaller window of vulnerability to transaction loss as opposed to all transactions being committed non-durably. By committing only every nth transaction durably or performing a durable commit every n seconds, an application can achieve a quicker response time while maintaining a small window of vulnerability to transaction loss. A user can elect to perform a durable commit of a critical transaction, such as one that deals with financial exchange, that cannot be vulnerable to loss. To enable periodic durable commits, an application does the following: Connects with setting the attribute When a durable commit is needed, the application can call the TimesTen creates one transaction log for each database, which is shared by all concurrent connections. A transaction log record is created for each database update, commit, and rollback. However, transaction log records are not generated for read-only transactions. Log records are first written to the transaction log buffer, which resides in the same shared memory segment as the database. The contents of the log buffer are then subsequently flushed to the latest transaction log file on disk. The transaction log is used to track all updates made within a transaction, so that those updates can be undone if the transaction is rolled back. Transaction logging enables recovery of transactions from checkpoint files and the transaction log, which were committed from the time of the last checkpoint operation after a system failure. If the transaction is non-durable, any committed transactions in the log buffer that have not been flushed to disk would be lost in the event of a system failure. The following sections describe how to manage and monitor the transaction log buffers and file: The following describes how to configure transaction log buffers and files: Transaction log buffers: There is one transaction log buffer for each database and the size of the transaction log buffer can be configured using the Transaction log files: The maximum size for the transaction log files are configured with the Note: It is important to verify at frequent intervals that there are no transaction log holds that could result in an excessive accumulation of transaction log files. If too many transaction log files accumulate and fill up available disk space, new transactions in the TimesTen database cannot begin until the transaction log hold is advanced and transaction log files are purged by the next checkpoint operation. The following sections describe transaction log operations, log holds, and accumulation of log files: Any transaction log file is kept until TimesTen determines it can be purged, w €ÿhich can occur under the following conditions: Transactions writing log records to the file have been committed or rolled back. These can be either local database transactions or XA transactions. Changes recorded in the file have been written to both checkpoint files. Changes recorded in the file have been replicated, if replication is enabled. Changes recorded in the file have been propagated to Oracle Database, if IMDB Cache is used and configured for that behavior. Changes recorded in the file have been reported to XLA, if XLA is used. Under normal TimesTen operating conditions, unneeded transaction log files are purged each time a checkpoint is initiated. A checkpoint can be initiated either through a configurable time interval with the If you are running out of disk space because of log files accumulating, use the Note: See "Checkpointing" in the Oracle In-Memory Database Cache Introduction for general information. See "Configure or turn off background checkpointing" for more details on Several TimesTen components or operations can cause transaction log holds. A transaction log hold prevents log files, beyond a certain point, from being purged until they are no longer needed. In normal circumstances, the log hold position is regularly advanced and log files are purged appropriately. However, if operations are not functioning properly and the hold position does not advance, there can be an excessive accumulation of log files beyond the hold position that can no longer be purged, which eventually fills available disk space. These components and operations include the following: Replication: There is a transaction log hold until the transmitting replication agent confirms that the log files have been fully processed by the receiving host. Possible failure modes include the following: The network is down or there is a standby crash and replication is unable to deliver data to one or more subscribers. If necessary, the application can direct that logs no longer be held, then duplicate the master database to the standby when normal operations resume. Criteria for when to do this includes the amount of time required to duplicate, the amount of available disk space on the master for log files, and the transaction log growth rate. The overall database transaction rate exceeds the ability of replication to keep the active and standby databases synchronized. An application can reduce the application transaction rate or the number of replicated tables. For more information, see "Improving replication performance" in the Oracle TimesTen In-Memory Database Replication Guide and "Troubleshooting Replication" in the Oracle TimesTen In-Memory Database Troubleshooting Guide. XLA: There is a transaction log hold until the XLA bookmark advances. A possible failure mode occurs when the bookmark becomes stuck, which can occur if an XLA application terminates unexpectedly or if it disconnects without first deleting its bookmark or disabling change-tracking. If a bookmark gets too far behind, the application can delete it. If the XLA reader process is still active, it must first be terminated, so that another XLA process can connect and delete the bookmark. Active standby pairs that replicate AWT cache groups: There is a transaction log hold until the replication agent confirms that the transaction corresponding to the log hold has been committed on the Oracle Database. With an active standby pair, the active database typically receives the confirmation from the standby database. If the standby database is down, the replication agent receives confirmation from Oracle Database directly. Possible failure modes include the following: Oracle Database is down or there is a lock or resource contention. The network is down, slow, or saturated. With an active standby pair, replication to the standby database falls behind. Check log holds on the standby database. The transaction rate to TimesTen exceeds the maximum sustainable rate that TimesTen can propagate to Oracle Database. For more information, see "Monitoring AWT cache groups" in the Oracle In-Memory Database Cache User's Guide and "Troubleshooting AWT Cache Groups" in the Oracle TimesTen In-Memory Database Troubleshooting Guide. Cache groups configured with Possible failure modes include the following: Replication from the active database to the standby database is impacted because the standby database falls behind due to large workloads resulting from The standby database is down or recovering, but has not been marked as For more information, see "Monitoring autorefresh cache groups" in the Oracle TimesTen In-Memory Database Troubleshooting Guide. Incremental TimesTen backup: There is a transaction log hold until the backup completes. A possible failure mode can occur if the incremental backup falls too far behind the most recent entries in the transaction log. For example, ensure that an unexpected burst of transaction activity cannot fill up available transaction log disk space due to the backup holding a log file that is too old. An application can perform another incremental backup to work around this situation. Long-running transaction or XA transaction: There is a transaction log hold until the transaction completes. A possible failure mode can occur if an application transaction does not commit or roll back for a long time, so that it becomes necessary for the application to terminate the long-running transaction. If necessary, you can roll back a transaction using the Options for periodic monitoring of excessive transaction log accumulation include the following: Call the Log file number, the offset of the hold position, and the type of hold, which can be checkpoint, replication, backup, XLA, long-running transaction, or long-running XA transaction Name of the checkpoint file for a checkpoint hold Name of the subscriber and the parallel track ID it uses for replication Backup path for a backup hold Name of the persistent subscription and process ID of the last process to open it for XLA Transaction ID for a long-running transaction XA XID for a long-running XA transaction For more information, see "ttLogHolds" in the Oracle TimesTen In-Memory Database Reference. Call the For more information, see "ttCkptHistory" in the Oracle TimesTen In-Memory Database Reference. Check the For more information, see "SYS.MONITOR" in the Oracle TimesTen In-Memory Database System Tables and Views Reference. For XLA, check the For more information, see "SYS.TRANSACTION_LOG_API" in the Oracle TimesTen In-Memory Database System Tables and Views Reference. The following sections describe transaction isolation and locking levels: Transaction isolation enables each active transaction to operate as if there were no other transactions active in the system. Isolation levels determine if row-level locks are acquired when performing read operations. When a statement is issued to update a table, locks are acquired to prevent other transactions from modifying the same data until the updating transaction completes and releases its locks. The Isolation connection attribute sets the isolation level for a connection. Isolation levels have no effect if using database-level locking because transactions cannot be run concurrently. The isolation level cannot be changed in the middle of a transaction. TimesTen supports the following two transaction isolation levels: ANSI Read Committed isolation: The read committed isolation level is the recommended mode of operation for most applications, and is the default mode. It enables transactions that are reading data to execute concurrently with a transaction that is updating the same data. TimesTen makes multiple versions of data items to allow non-serializable read and write operations to proceed in parallel. Read operations do not block write operations and write operations do not block read operations, even when they read and write the same data. Read operations do not acquire locks on scanned rows. Write operations acquire locks that are held until the transaction commits or rolls back. Readers share a committed copy of the data, whereas a writer has its own uncommitted version. Therefore, when a transaction reads an item that is being updated by another in-progress transaction, it sees the committed version of that item. It cannot see an uncommitted version of an in-progress transaction. Read committed isolation level provides for better concurrency at the expense of decreased isolation because of the possibility of non-repeatable reads or phantom rows within a transaction. If an application executes the same query multiple times within the same transaction, the commit of an update from another transaction may cause the results from the read operation to retrieve different results. A phantom row appears in modified form in two different reads, in the same transaction, due to early release of read locks during the transaction. To set read committed isolation level, if previously modified since this is the default, do one of the following: ODBC applications execute the Connect with When using ANSI Serializable isolation: All locks acquired within a transaction by a read or write operation are held until the transaction commits or rolls back. Read operations block write operations, and write operations block read operations. As a result, a row that has been read by one transaction cannot be updated or deleted by another transaction until the original transaction terminates. Similarly, a row that has been inserted, updated or deleted by one transaction cannot be accessed in any way by another transaction until the original transaction terminates. Serializable isolation level provides for repeatable reads and increased isolation at the expense of decreased concurrency. A transaction that executes the same query multiple times within the same transaction is guaranteed to see the same result set each time. Other transactions cannot update or delete any of the returned rows, nor can they insert a new row that satisfies the query predicate. To set the isolation level to Serializable, do one of the following: ODBC applications execute the Connect with When using To ensure that materialized views are always in a consistent state, all view maintenance operations are performed under Serializable isolation, even when the transaction is in read committed isolation. This means that the transaction obtains read locks for any data items read during view maintenance. However, the transaction releases the read locks at the end of the Note: TimesTen supports row-level locks, table-level locks and database-level locks: Note: Row-level locking: Transactions usually obtain locks on the individual rows that they access. Row-level locking is the recommended mode of operation because it provides the finest granularity of concurrency control. It allows concurrent transactions to update different rows of the same table. However, row-level locking requires space in the database's temporary partition to store lock information. Row-level locking is the default. However, if it has been modified to another type of locking and you want to re-enable row-level locking, do one of the following: Set the Execute the Execute the Note: Table-level locking: Table-level locking is recommended when concurrent transactions access different tables or a transaction accesses most of the rows of a particular table. Table-level locking provides better concurrency than database-level locking. Row-level locking provides better concurrency than table-level locking. Table-level locking requires only a small amount of space in the temporary partition to store lock information. Table-level locking provides the best performance for the following: Queries that access a significant number of rows of a table When there are very few concurrent transactions that access a table When temporary space is inadequate to contain all row locks that an operation, such as a large insert or a large delete, might acquire To enable table-level locking, execute the If both table-level and row-level locking are disabled, TimesTen defaults to row-level locking. If both table-level and row-level locking are enabled, TimesTen chooses the locking scheme that is more likely to have better performance. Even though table-level locking provides better performance than row-level locking because of reduced locking overhead, the optimizer will often choose row-level locking for better concurrency. For more information, see "ttOptSetFlag" in the Oracle TimesTen In-Memory Database Reference. Note: Database-level locking: Database-level locking serializes all transactions, which effectively allows no concurrency on the database. When a transaction is started, it acquires an exclusive lock on the database, which ensures that there is no more than one active transaction in the database at any given time. It releases the lock when the transaction is completed. Database-level locking often provides better performance than row-level locking, due to reduced locking overhead. In addition, it provides higher throughput than row-level locking when running a single stream of transactions such as a bulk load operation. However, its applicability is limited to applications that never execute multiple concurrent transactions. With database-level locking, every transaction effectively runs in ANSI Serializable isolation, since concurrent transactions are disallowed. To enable database-level locking, do one of the following: Set the Execute the Set the If a statement within a transaction waits for a lock and the lock wait interval has elapsed, an error is returned. After receiving the error, the application can reissue the statement. Lock wait intervals are imprecise due to the scheduling of the database's managing subdaemon process to detect lock timeouts. This imprecision does not apply to zero-second timeouts, which are always immediately reported. The lock wait interval does not apply to blocking checkpoints. The database's managing subdaemon process checks every two seconds to see if there is a deadlock in the database among concurrent transactions. If a deadlock occurs, an error is returned to one of the transactions involved in the deadlock cycle. The transaction that receives the error must rollback in order to allow the other transactions involved in the deadlock to proceed. A checkpoint operation saves the in-memory image of a database to disk files, known as checkpoint files. By default, TimesTen performs background checkpoints at regular intervals. Checkpointing may generate a large amount of I/O activity and have a long execution time depending on the size of the database and the number of database changes since the most recent checkpoint. Note: Temporary databases do not initiate checkpointing. See "Database persistence" for more information on temporary databases. The following sections describe checkpoint operations and how you can manage them: A checkpoint operation has two primary purposes. Decreases the amount of time required for database recovery, because it provides a more up-to-date database image on which recovery can begin. Makes a portion of the transaction log unneeded for any future database recovery operation, typically allowing one or more transaction log files to be deleted. Both of these functions are very important to TimesTen applications. The reduction in recovery time is important, as the amount of a transaction log needed to recover a database has a direct impact on the amount of downtime seen by an application after a system failure. The removal of unneeded transaction log files is important because it frees disk space that can be used for new transaction log files. In addition, the fewer transaction log files you have, the less time is required to load a database into memory. If these files were never removed, they would eventually consume all available space in the transaction log directory's file system, causing database operations to fail due to log space exhaustion. Each TimesTen database has two checkpoint files, named TimesTen uses the most recent consistent checkpoint file and the transaction log to recover the database to its most recent transaction-consistent state after a database shutdown or system failure. If any errors occur during this process, or if the more recent checkpoint image is incomplete, then recovery restarts using the other checkpoint file. TimesTen also creates TimesTen supports two types of database checkpoint operations: Fuzzy checkpoints, or non-blocking checkpoints, allow transactions to execute against the database while the checkpoint is in progress. Fuzzy checkpoints do not obtain lo
)õÖcks of any kind, and therefore have a minimal impact on other database activity. Because transactions may modify the database while a checkpoint operation is in progress, the resulting checkpoint file may contain both committed and uncommitted transactions. Furthermore, different portions of the checkpoint image may reflect different points in time. For example, one portion may have been written before a given transaction committed, while another portion was written afterward. The term "fuzzy checkpoint" derives its name from this fuzzy state of the database image. To recover the database when the checkpoint files were generated from fuzzy checkpoint operations, TimesTen requires the most recent consistent checkpoint file and the transaction log to bring the database into its most recent transaction-consistent state. Transaction-consistent checkpoints, also known as blocking checkpoints, obtain an exclusive lock on the database for a portion of the checkpoint operation, blocking all access to the database during that time. The resulting checkpoint image contains all committed transactions prior to the time the checkpoint operations acquired the exclusive lock on the database. Because no transactions can be active while the database lock is held, no modifications made by in-progress transactions are included in the checkpoint image. TimesTen uses the most recent consistent checkpoint file to recover the database to transaction-consistent state at the time of the last successful checkpoint operation completed. It uses the transaction log files to recover the database to its most recent transaction-consistent state after a database shutdown or system failure. To request a transaction-consistent checkpoint, an application uses the The default behavior for TimesTen checkpoints is as follows: TimesTen performs periodic fuzzy checkpoints in the background. You can modify this behavior. See "Configure or turn off background checkpointing" for more information. TimesTen performs a transaction-consistent checkpoint operation of a database just before the database is unloaded from memory. See "Transaction-consistent checkpoints". You can manage and monitor checkpoints with the following connection attributes and built-in procedures: The following sections describe how to manage checkpointing: By default, TimesTen performs periodic fuzzy checkpoints in the background. Therefore, applications rarely need to issue manual checkpoints. However, if an application wishes to issue a manual checkpoint, it can call the Using attributes or built-in procedures, you can configure TimesTen to checkpoint either when the transaction log files contain a certain amount of data or at a specific frequency. To configure checkpointing in TimesTen, do the following: Configure the The The To turn off background checkpointing, set both the Alternatively, you can configure background checkpointing or turn it off by executing the Note: Use the By default, there is no limit to the rate at which checkpoint data is written to disk. You can use the Setting a rate too low can cause checkpoints to take an excessive amount of time and cause the following problems: Delay the purging of unneeded transaction log files Delay the start of backup operations Increase recovery time. When choosing a rate, you should take into consideration the amount of data written by a typical checkpoint and the amount of time checkpoints usually take. Both of these pieces of information are available through the If a running checkpoint appears to be progressing too slowly when you evaluate the progress of this checkpoint with the Perform the following to calculate the checkpoint rate: Call the For any given checkpoint, subtract the starttime from the endtime. Divide the number of bytes written by this elapsed time in seconds to get the number of bytes per second. Divide this number by 1024*1024 to get the number of megabytes per second. When setting the checkpoint rate, you should consider the following: The specified checkpoint rate is only approximate. The actual rate of the checkpoint may be below the specified rate, depending on the hardware, system load and other factors. The above method may underestimate the actual checkpoint rate, because the starttime and endtime interval includes other checkpoint activities in addition to the writing of dirty blocks to the checkpoint file. The When adjusting the checkpoint rate, you may also need to adjust the checkpoint frequency, as a slower rate makes checkpoints take longer, which effectively increases the minimum time between checkpoint beginnings. This chapter provides detailed information on the basic components in a TimesTen database and simple examples of how you can use SQL to manage these components. For more information about SQL, see the Oracle TimesTen In-Memory Database SQL Reference. For information on how to execute SQL from within an application, see the appropriate TimesTen developer's guide. This chapter includes the following topics: The following sections describe the main TimesTen database elements and features: A TimesTen database has the following permanent components: Tables. The primary components of a TimesTen database are the tables that contain the application data. See "Understanding tables". Materialized Views. Read-only tables that hold a summary of data selected from one or more "regular" TimesTen tables. See "Understanding materialized views". Views. Logical tables that are based on one or more tables called detail tables. A view itself contains no data. See "Understanding views". Indexes. Indexes on one or more columns of a table may be created for faster access to tables. See "Understanding indexes". Rows. Every table consists of 0 or more rows. A row is a formatted list of values. See "Understanding rows". System tables. System tables contain TimesTen metadata, such as a table of all tables. See "System Tables" in the Oracle TimesTen In-Memory Database System Tables and Views Reference. There are also many temporary components, including prepared commands, cursors and locks. When access control is enabled, the TimesTen Data Manager authenticates user names with passwords. TimesTen Client/Server also authenticates users with passwords. Applications should choose one UID for the application itself because by default the login name that is being used to run the application becomes the owner of the database. If two different logins are used, TimesTen may have difficulty finding the correct tables. If you omit the Users cannot access TimesTen databases as user When a database is created, it has either the permanent or temporary attribute set: Note: Permanent databases are stored to disk automatically through a procedure called checkpointing. TimesTen automatically performs background checkpoints based on the settings of the connection attributes Temporary databases are not stored to disk. A temporary database is automatically destroyed when no applications are connected to it; that is, when the last connection disconnects or when there is a system or application failure. TimesTen removes all disk-based files when the last application disconnects. A temporary database cannot be backed up or replicated. Temporary databases are never fully checkpointed to disk, although Checkpoint operations can have significant overhead for permanent databases, depending on database size and activity, but have very little impact for temporary databases. Checkpoints are still necessary to remove transaction log files. However, temporary databases do have a transaction log, which is periodically written to disk, so transactions can be rolled back. The amount of data written to the transaction log for temporary databases is less than that written for permanent databases, allowing better performance for temporary databases. Recovery is never performed for temporary databases. You can increase your performance with temporary databases. If you do not need to save the database to disk, you can save checkpoint overhead by creating a temporary database. Details for setting up a temporary database are described in "Setting up a temporary database". A TimesTen table consists of rows that have a common format or structure. This format is described by the table's columns. The following sections describes tables, its columns and how to manage them: This section includes the following topics: When you create the columns in the table, the column names are case-insensitive. Each column has the following: A data type Optional nullability, primary key and foreign key properties An optional default value Unless you explicitly declare a column The format of TimesTen columns cannot be altered. It is possible to add or remove columns but not to change column definitions. To add or remove columns, use the The in-memory layout of the rows of a table is designed to provide fast access to rows while minimizing wasted space. TimesTen designates each An in-line column has a fixed length. All values of fixed-length columns of a table are stored row wise. A not inline column (also referred to as an out-of-line column) has a varying length. Some The maximum sizes of in-line and out-of-line portions of a row are listed in "Using the ttIsql tablesize command". When you create a table, you can specify default values for the columns. The default value you specify must be compatible with the data type of the column. You can specify one of the following default values for a column: A constant value If you use the A TimesTen table is identified uniquely by its owner name and table name. Every table has an owner. By default, the owner is the user who created the table. Tables created by TimesTen, such as system tables, have the owner name To uniquely refer to a table, specify both its owner and name separated by a period ("."), such as A name is an alphanumeric value that begins with a letter. A name can include underscores. The maximum length of a table name is 30 characters. The maximum length of an owner name is also 30 characters. TimesTen displays all table, column and owner names to upper case characters. See "Names, Namespace and Parameters" in the Oracle TimesTen In-Memory Database SQL Reference for additional information. Applications access tables through SQL statements. The TimesTen query optimizer automatically chooses a fast way to access tables. It uses existing indexes or, if necessary, creates temporary indexes to speed up access. For improved performance, applications should explicitly create indexes for frequently searched columns because the automatic creation and destruction of temporary indexes incurs a performance overhead. For more details, see "Tune statements and use indexes". The creator of a TimesTen table can designate one or more columns as a primary key to indicate that duplicate values for that set of columns should be rejected. Primary key columns cannot be nullable. A table can have at most one primary key. TimesTen automatically creates a range index on the primary key to enforce uniqueness on the primary key and to guarantee fast access through the primary key. Once a row is inserted, its primary key columns cannot be modified, except to change a range index to a hash index. Although a table may have only one primary key, additional uniqueness properties may be added to the table using unique indexes. See "CREATE INDEX" in the Oracle TimesTen In-Memory Database SQL Reference for more information. Note: A table may also have one or more foreign keys through which rows correspond to rows in another table. Foreign keys relate to a primary key or uniquely indexed columns in the other table. Foreign keys use a range index on the referencing columns. See "CREATE TABLE" in the Oracle TimesTen In-Memory Database SQL Reference for more information. In addition to tables created by applications, a TimesTen database contains system tables. System tables contain TimesTen metadata such as descriptions of all tables and indexes in the database, as well as other information such as optimizer plans. Applications may query system tables just as they query user tables. Applications may not update system tables. TimesTen system tables are described in the "System Tables" chapter in the Oracle TimesTen In-Memory Database System Tables and Views Reference. Note: To perform any operation that creates, drops or manages a table, the user must have the appropriate privileges, which are described along with the syntax for all SQL statements in the "SQL Statements" chapter in the Oracle TimesTen In-Memory Database SQL Reference. This section includes the following topics: To create a table, use the SQL statement Example 7-1 Create a table The following SQL statement creates a table, called Example 7-2 Create a table with a hash index This example creates a table, called Increasing the size of a TimesTen database can be done on first connect. To avoid having to increase the size of a database, it is important not to underestimate the eventual database size. Use the utility You can also calculate the size of an existing table with the You can define an aging policy for one or more tables in your database. An aging policy refers to the type of aging and the aging attributes, as well as the aging state ( You can define an aging policy for a new table with the You cannot specify aging on the following types of tables: Global temporary tables Detail tables for materialized views You can also implement aging in cache groups. See "Implementing aging in a cache group" in the Oracle In-Memory Database Cache User's Guide. This section includes the following topics: Usage-based aging enables you to maintain the amount of memory used in a database within a specified threshold by removing the least recently used (LRU) data. Define LRU aging for a new table by using the Use the Note: The following table summarizes the LRU aging attributes: If you set a new value for If a row has been accessed or referenced since the last aging cycle, it is not eligible for LRU aging. A row is considered to be accessed or referenced if one of the following is true: The row is used to build the result set of a The row has been flagged to be updated or deleted. The row is used to build the result set of an You can use the Enable or disable the aging state on a table that has an aging policy defined by using the Add an LRU aging policy to an existing table by using the Drop aging on a table by using the Use the To change aging from LRU to time-based on a table, first drop aging on the table by using the Note: Time-based aging removes data from a table based on the specified data lifetime and frequency of the aging process. Specify a time-based aging policy for a new table with the The Your application updates the values of the timestamp column. If the value of this column is unknown for some rows and you do not want the rows to be aged, then define the column with a large default value. You can create an index on the timestamp column for better performance of the aging process. Note: You cannot drop the timestamp column from a table that has a time-based aging policy. If the data type of the timestamp column is The value in the timestamp column is subtracted from Use the Use the Enable or disable the aging state on a table with a time-based aging policy by using the Change the aging cycle on a table with a time-based aging policy by using the Change the lifetime by using the Add time-based aging to an existing table with no aging policy by using the Drop aging on a table by using the Use the To change the aging policy from time-based aging to LRU aging on a table, first drop time-based aging on the table. Then add LRU aging by using the Tables that are related by foreign keys must have the same aging policy. If LRU aging is in effect and a row in a child table has been recently accessed, then neither the parent row nor the child row will be deleted. If time-based aging is in effect and a row in a parent table is a candidate for aging out, then the parent row and all of its children will be deleted. If a table has Use the When you call The aging process starts only once as a result of calling If the aging state is already set to You can control aging externally by disabling aging by using the Use For active standby pairs, implement aging on the active master database. Deletes that occur as a result of aging will be replicated to the standby master database and the read-only subscribers. If a failover to the standby master database occurs, aging is enabled on the database after its role changes to For all other types of replication schemes, implement aging separately on each node. The aging policy must be the same on all nodes. If you implement LRU aging on a multimaster replication scheme used as a hot standby, LRU aging may provide unintended results. After a failover, you may not have all of the desired data because aging occurs locally. A view is a logical table that is based on one or more tables. The view itself contains no data. It is sometimes called a non-materialized view to distinguish it from a materialized view, which does contain data that has already been calculated from detail tables. Views cannot be updated directly, but changes to the data in the detail tables are immediately reflected in the view. To choose whether to create a view or a materialized view, consider where the cost of calculation lies. For a materialized view, the cost falls on the users who update the detail tables because calculations must be made to update the data in the materialized views. For a nonmaterialized view, the cost falls on a connection that queries the view, because the calculations must be made at the time of the query. To perform any operation that creates, drops or manages a view, the user must have the appropriate privileges, which are described along with the syntax for all SQL statements in the "SQL Statements" chapter in the Oracle TimesTen In-Memory Database SQL Reference. This section includes the following topics: To create a view, use the This selects columns from the detail tables to be used in the view. For example, create a view from the table Now create a view from an aggregate query on the table The A The following cannot be used in a Arguments Temporary tables Each expression in the select list must have a unique name. A name of a simple column expression would be that column's name unless a column alias is defined. RowId is considered an expression and needs an alias. No 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. The The following statement drops the Views have the following restrictions: When a view is referenced in the A view cannot be dropped with a A view cannot be altered with an Referencing a view can fail due to dropped or altered detail tables. The following sections describes materialized views and how to manage them: A materialized view is a read-only table that maintains a summary of data selected from one or more regular TimesTen tables. The TimesTen tables queried to make up the result set for the materialized view are called detail tables. Note: Figure 7-1 shows a materialized view created from detail tables. An application updates the detail tables and can select data from the materialized view. There are two types of materialized views based upon how the result set for the materialized view is updated. In addition, learn when to use each type of materialized views in the section: "When to use synchronous or asynchronous materialized views". The synchronous materialized view, by default, updates the result set data from the detail tables at the time of the detail table transaction. Every time data is updated in the detail tables, the result set is updated. Thus, the synchronous materialized view is never out of sync with the detail tables. However, this can affect your performance. A single transaction, the user transaction, executes the updates for both the detail table and any synchronous materialized views. The materialized view is populated and it is in sync with the detail tables at creation. When the detail tables are updated, the asynchronous materialized views are not updated immediately. At any moment, they can be out of sync with the corresponding detail tables. The asynchronous materialized view defers updates to the result set as a trade-off for performance. You decide when and how the result set is refreshed either manually by the user or automatically within a pre-configured interval. The asynchronous materialized view is always refreshed in its own transaction, not within the user transaction that updates the detail tables. Thus, the user transaction is not blocked by any updates for the asynchronous materialized view. The asynchronous refresh may use either of the following refresh method configurations: To facilitate a The detail table cannot be dropped if there is an associated materialized view or materialized view log. Note: The following sections provide guidelines on when to use synchronous or asynchronous materialized views: If a synchronous materialized view has joins or uses aggregate functions, there is a super lock effect. For example, if you have a single table with a synchronous materialized view that aggregates on average 1000 rows into 1. When you update a row in the detail table of the synchronous materialized view, you lock that row for the remainder of the transaction. Any other transaction that attempts to update that row blocks and waits until the transaction commits. But since there is a synchronous materialized view on that table, the materialized view is also updated. The single row in the materialized view is locked and updated to reflect the change. However, there are 999 other rows from the base table that also aggregate to that same materialized view row. These 999 other base table rows are also effectively locked because if you try to update any of them, you will block and wait while retrieving the lock on the materialized view row. This is referred to as a super lock. The same effect occurs across joins. If you have a synchronous materialized view that joins five tables and you update a row in any one of the five tables, you will have a super lock on all the rows in the other four tables that join to the one that you updated. Obviously, the combination of joins and aggregate functions compound the problem for synchronous materialized views. However, asynchronous materialized views with COMPLETE refresh diminish the super lock because the locks on the asynchronous materialized view rows with COMPLETE refresh are only held during the refresh process. The super locks with synchronous materialized views will be held until the updating transaction commits. Thus, if you have short transactions, then super locks on synchronous materialized view are not a problem. However, if you have long transactions, use asynchronous materialized views with COMPLETE refresh that minimize the effect of any super lock. Synchronous materialized views are always fresh and they always return the latest data. Asynchronous materialized views can become stale after an update until refreshed. If you must have the most current data all the time, use synchronous materialized views. However, you may consider using asynchronous if your application does not need the most current data. For example, you may execute a series of analytical queries each with variations. In this case, you can use an asynchronous materialized view to isolate the differences that result from the query variations from the differences that result from newly arrived or updated data. An asynchronous materialized view is not updated in the user transaction, which updates the detail tables. The refresh of an asynchronous materialized view is always performed in an independent transaction. This means that the user is free to execute any other transaction. By comparison, for synchronous materialized views, a single transaction executes the updates for both the detail table and any synchronous materialized views, which does affect your performance. While the asynchronous materialized view logs for asynchronous materialized views with FAST refresh incur overhead, it is generally less overhead than the cost of updating a synchronous materialized view. This is especially true even if the asynchronous materialized view is complicated with joins. For asynchronous materialized views with COMPLETE refresh, there is no overhead at the time of updating the detail table. You can defer asynchronous materialized view maintenance cost. The asynchronous materialized view log costs less than the incremental maintenance of the synchronous materialized view because the asynchronous materialized view logs perform simple inserts, whereas synchronous materialized view maintenance has to compute the delta for the materialized view and joins and then apply results in an update operation. Updates are more expensive than inserts. The cost difference reduces if the synchronous materialized view is simple in structure. This section includes the following topics: To create a materialized view, use the SQL statement Note: If the owner has these privileges revoked for any of the detail tables on which the materialized view is created, the materialized view becomes invalid. See "Object privileges for materialized views" for details. When creating a materialized view, you can establish primary keys and the size of the hash table in the same manner as described for tables in "Primary keys, foreign keys and unique indexes". The materialized view examples are based on the following two tables: The following sections provide details and examples for creating materialized views: A synchronous materialized view is automatically updated each time the detail tables are updated. You can create a synchronous materialized view with the The following creates a synchronous materialized view, named An asynchronous materialized view is updated as specified by the refresh method and refresh interval, which are configured during the creation of the materialized view. When you create an asynchronous materialized view, you specify the Refresh method: For the asynchronous materialized view, specify either Note: Refresh interval: Manual update: If the refresh interval is not specified, the interval defaults to manual update. You can manually refresh the view by using the Specify refresh after every commit: When you specify Specify interval: The asynchronous materialized view is updated at a specified interval when you use the This clause specifies that the materialized view will be refreshed at the specified interval. The last refresh time is saved in order to determine the next refresh time. Refresh is skipped if there are no changes to the any of the detail tables of the asynchronous materialized view since the last refresh. If you want to modify a configured refresh interval, you must drop and recreate the asynchronous materialized view. If you use the The following example creates an asynchronous materialized view that uses Note: The materialized view log for the Once you create the materialized view log for both the The €ÿfollowing example creates an asynchronous materialized view named If you want to manually refresh the materialized view, execute the The To drop any materialized view, execute the The following statement drops the When there are no asynchronous materialized views referencing a table, the materialized view log on that table can be dropped. For example, if you have dropped the materialized view The syntax for all SQL statements is provided in the "SQL Statements" chapter in the Oracle TimesTen In-Memory Database SQL Reference. Materialized view logs are represented in the TimesTen system tables as a table named A materialized view is a read-only table that cannot be updated directly. This means a materialized view cannot be updated by an For example, any attempt to update a row in a materialized view generates the following error: Readers familiar with other implementations of materialized views should note the following characteristics of TimesTen views: Detail tables can be replicated, but materialized views cannot. Neither a materialized view nor its detail tables can be part of a cache group. No referential indexes can be defined on the materialized view. To drop a materialized view must use the You cannot alter a materialized view. You must use the Materialized views must be explicitly created by the application. The TimesTen query optimizer has no facility to automatically create materialized views. The TimesTen query optimizer does not rewrite queries on the detail tables to reference materialized views. Application queries must directly reference views, if they are to be used. There are some restrictions to the SQL used to create materialized views. See "CREATE MATERIALIZED VIEW" in the Oracle TimesTen In-Memory Database SQL Reference for details. The following sections describes performance implications for each type of materialized view: For managing performance, you can defer the refresh of the materialized view until an optimal time. Rows in the materialized view logs, detail table and materialized view may be locked during the refresh. If these locks interfere with the user transaction updating the detail tables, then the user can adjust the refresh interval. If performance is the highest priority and the asynchronous materialized view can be out of sync with the detail tables, set the refresh interval to execute when the system load is low. FAST refresh incrementally updates the materialized view based on the changes captured in the materialized view log. The time for this refresh depends on the number of modifications captured in the materialized view log and the complexities of the Update table statistics on the detail table, materialized view log tables and the materialized view at periodic intervals to improve the refresh performance. If the view involves joins, update table statistics before inserting any row in any of the detail tables. Table statistics can be updated using one of two built-in procedures for computing statistics: Note: A complete refresh is similar to the initial loading of the materialized view at creation time. The time for this refresh depends on the number of rows in the detail tables. The performance of Nature of the materialized view: How many detail tables, whether outer join or aggregation is used. Which indexes are present on the detail table and on the materialized view. How many materialized view rows will be affected by the change. A view is a persistent, up-to-date copy of a query result. To keep the view up to date, TimesTen must perform "view maintenance" when you change a view's detail table. For example, if you have a view named View maintenance needs appropriate indexes just like regular database operations. If they are not there, view maintenance will perform poorly. All update, insert, or delete statements on detail tables have execution plans, as described in "The TimesTen Query Optimizer". For example, an update of a row in For fast view maintenance, you should evaluate the plans for all the operations that update the detail tables, as follows: Examine all the Then the keys to note are ( Ensure that the view selects all of those key columns. In this example, the view should select Create an index on the view on each of those keys. In this example, the view should have two indexes, one on ( With this method, when you update a detail table, your The above method may not always work, however. For example, an application may have many different methods to update the detail tables. The application would have to select far too many items in the view or create too many indexes on the view, taking up more space or more performance than you might wish. An alternative method is as follows: For each table in the view's For each of those tables, make sure the view selects its rowids. In this example, the view should select Create an index on the view on each of those rowid columns. In this example, the columns might be called With this method, view maintenance is done on a row-by-row basis, rather than on a batch basis. But the rows can be matched very efficiently between a view and its detail tables, which speeds up the maintenance. It is generally not as fast as the first method, but it is still good. Indexes are auxiliary data structures that greatly improve the performance of table searches. You can use the Index Advisor to recommend indexes for a particular SQL workload. For more details, see "Using the Index Advisor to recommend indexes". Indexes are used automatically by the query optimizer to speed up the execution of a query. For information about the query optimizer, see "The TimesTen Query Optimizer". You can designate an index as unique, which means that each row in the table has a unique value for the indexed column or columns. Unique indexes can be created over nullable columns. In conformance with the SQL standard, multiple NULL values are permitted in a unique index. When sorting data values, TimesTen considers NULL values to be larger than all non-NULL values. See the Oracle TimesTen In-Memory Database SQL Reference for more information on NULL values. To perform any operation that creates, drops or alters an index, the user must have the appropriate privileges, which are described along with the syntax for all SQL statements in the "SQL Statements" chapter in the Oracle TimesTen In-Memory Database SQL Reference. The following sections describe how to manage your index: TimesTen provides three types of indexes to enable fast access to tables. Hash Indexes. Hash indexes are useful for finding rows with an exact match on one or more columns. Hash indexes are useful for doing equality searches. TimesTen currently supports a maximum of one hash index per table. A hash index is created with the The "CREATE TABLE" section of the Oracle TimesTen In-Memory Database SQL Reference discusses in detail the automatic creation of hash indexes. For an example of how to create a hash index when creating the table, see Example 7-2. Range Indexes. Range indexes are useful for finding rows with column values within a certain range. You can create range indexes over one or more columns of a table. Up to 32 range indexes may be created on one table. Range indexes and equijoins can be used for equality and range searches, such as greater than or equal to, less than or equal to, and so on. If you have a primary key on a field and want to see if The "CREATE INDEX" section of the Oracle TimesTen In-Memory Database SQL Reference discusses in describes how to create range indexes. Note: Bitmap Indexes. Bitmap indexes are useful when searching and retrieving data from columns with low cardinality. That is, these columns can have only a few unique possible values. Bitmap indexes encode information about a unique value in a row in a bitmap. Each bit in the bitmap corresponds to a row in the table. Use a bitmap index for columns that do not have many unique values. An example of such a column is a column that records gender as one of two values. Bitmap indexes increase the performance of complex queries that specify multiple predicates on multiple columns connected by See "CREATE INDEX" in the Oracle TimesTen In-Memory Database SQL Reference for how to create and more information on bitmap indexes. Note: To create an index, execute the SQL statement Every index has an owner. The owner is the user who created the underlying table. Indexes created by TimesTen itself, such as indexes on system tables, are created with the user name Example 7-4 Create an index Create an index You can also create a hash index by creating a primary key or using the You can change a range index to a hash index with the To uniquely refer to an index, an application must specify both its owner and name. If the application does not specify an owner, TimesTen looks for the index first under the user name of the caller, then under the user name To drop a TimesTen index, execute the Increasing the size of a TimesTen database can be done on first connect. To avoid having to increase the size of a database, it is important not to underestimate the eventual database size. Use the utility The right set of indexes can make a difference in query performance. The Index Advisor can be used to recommend indexes for improving the performance of a specific SQL workload. The Index Advisor is intended for read-intensive complex queries. The use of the Index Advisor is not recommended for a write-intensive workload. The Index Advisor evaluates a SQL workload and recommends indexes that can improve the performance for the following: joins, single table scans, and The Index Advisor generates the Indexes that are duplicates of existing indexes. Indexes for tables or columns of tables that are created and dropped during a SQL workload. However, you could add the Indexes that cannot be created, such as a unique index for a data set where the data is not unique. In this case, you should ignore this recommendation. The Index Advisor does not cover the following: It does not optimize for memory use. It does not consider maintenance costs. It does not recommend special types of indexes, such as bitmap or hash indexes. It will not recommend that existing indexes be dropped if they are not useful. It will not recommend indexes for global temporary tables. The recommended steps to use the Index Advisor are as follows: Before you execute the Index Advisor, you should optionally perform the following: Since the Index Advisor relies on the query plan, set any relevant optimizer hints using the Update statistics for tables included in the SQL workload and force statements to be re-prepared during the capture. This provides the most up-to-date statistics for the data collection and causes the statements to be re-prepared based on the latest statistics. Update the statistics for tables included in the SQL workload with one of the following built-in procedures: The The The Note: The following example estimates statistics for all tables for the current user by evaluating a random sample of ten percent of the rows in these tables. It also invalidates all commands already prepared that reference these tables. Execute the Execute the Run the SQL workload. Execute the Note: When you execute the In the if you invoke The Perform the collection of index information using the current execution of the SQL workload. Base the collection of index information not on a current execution of the SQL workload, but on existing computed statistics and query plan analysis. In this scenario, the SQL statements have been prepared, but not executed. This mode can only be executed with a connection-level capture. To complete the capture, execute the If a connection fails during a capture, the following occurs: If the capture is a connection-level capture, the capture ends and all associated resources are freed. If the capture is a database-level capture, the capture continues until another user with If temporary space becomes full during a capture, an active capture ends and the data collected during the capture is saved. Note: The following example starts a collection for the Index Advisor at the connection-level for the current execution of a SQL workload: The following example ends the collection for the connection-level capture: Note: Execute the Execute the Note: After a DBA has evaluated the recommended index creation statements, apply the desired index creation recommendations. The Note: The The data capture was started and has not ended. A previous capture that was started and stopped, and the data was not deleted. Note: The rows returned include the following information: The capture state: Returns 0 if a capture is completed. Returns 1 if a capture is still in progress. The connection identifier, if appropriate. The capture level and mode set for this capture. The number of prepared and executed statements during the capture interval. The time that the capture was started and stopped. The following shows capture information for a completed connection-level capture for 363 prepared statements and 369 executed statements: Note: The To request index recommendations for a connection-level capture, execute The returned row contains: The following example provides the Note: After you have applied the Save the current state of the table statistics. You can generate a set of SQL statements with the Drop the captured data collected for the Index Advisor with the Return to "Prepare for executing the Index Advisor" and repeat these steps until a SQL workload is executed with no more index recommendations. You can keep updating the statistics for the tables on which the new indexes were applied and re-execute the Index Advisor to see if any new indexes are now recommended. Execute the Note: The following example returns a set of built-in procedure commands that would be required to be executed to restore the statistics for the The Note: The following shows the flow of a data collection for a SQL workload and the resulting index advice provided by the Index Advisor built-in procedures. Rows are used to store TimesTen data. TimesTen supports several data types for fields in a row, including: One-byte, two-byte, four-byte and eight-byte integers. Four-byte and eight-byte floating-point numbers. Fixed-length and variable-length character strings, both ASCII and Unicode. Fixed-length and variable-length binary data. Fixed-length fixed-point numbers. Time represented as Date represented as Timestamp represented as The "Data Types" section in the Oracle TimesTen In-Memory Database SQL Reference contains a detailed description of these data types. To perform any operation for inserting or deleting rows, the user must have the appropriate privileges, which are described along with the syntax for all SQL statements in the "SQL Statements" chapter in the Oracle TimesTen In-Memory Database SQL Reference. The following sections describe how to manage your rows: To insert a row, execute Example 7-6 Insert a row in a table To insert a row in the table Note: A synonym is an alias for a database object. Synonyms are often used for security and convenience, because they can be used to mask object name and object owner. In addition, you can use a synonym to simplify SQL statements. Synonyms provide independence in that they permit applications to function without modification regardless of which object a synonym refers to. Synonyms can be used in DML statements and some DDL and IMDB cache statements. Synonyms are categorized into two classes: Private synonyms: A private synonym is owned by a specific user and exists in the schema of a specific user. A private synonym shares the same namespace as other object names, such as table names, view names, sequence names, and so on. Therefore, a private synonym cannot have the same name as a table name or a view name in the same schema. Public synonyms: A public synonym is owned by all users and every user in the database can access it. A public synonym is accessible for all users and it does not belong to any user schema. Therefore, a public synonym can have the same name as a private synonym name or a table name. In order to create and use synonyms, the user must have the correct privileges, which are described in "Object privileges for synonyms". After synonyms are created, they can be viewed using the following views: For full details on these views, see the Oracle TimesTen In-Memory Database Reference. Create the synonym with the In order to execute the Object types for synonyms: The Note: Naming considerations: A private synonym shares the same namespace as all other object names, such as table names and so on. Therefore, a private synonym cannot have the same name as a table name or other objects in the same schema. A public synonym is accessible for all users and does not belong to any particular user schema. Therefore, a public synonym can have the same name as a private synonym name or other object name. However, you cannot create a public synonym that has the same name as any objects in the SYS schema. In the following example, the user creates a private synonym of For full details, more examples, and rules on creating or replacing a synonym, see the "CREATE SYNONYM" section in the Oracle TimesTen In-Memory Database SQL Reference. Use the For example, the following drops the public synonym In order drop a public synonym or a private synonym in another user's schema, the user must have the appropriate privileges. For full details, more examples, and rules on creating or replacing a synonym, see the "DROP SYNONYM" section in the Oracle TimesTen In-Memory Database SQL Reference. When a synonym or object is newly created or dropped, some SQL queries and DDL statements may be invalidated or recompiled. The following lists the invalidation and recompilation behavior for SQL queries and DDL statements: All SQL queries that depend on a public synonym are invalidated if you create a private synonym with the same name for one of the following objects: private synonym table view sequence materialized view cache group PL/SQL object including procedures, functions, and packages. All SQL queries that depend on a private synonym or schema object are invalidated when a private synonym or schema object is dropped. You can open client/server connections across a network to the TimesTen database with the TimesTen Client and TimesTen Server. The following sections describe the TimesTen Client/Server and how to connect using them: The TimesTen Server is a process that runs on a server machine that takes network requests from TimesTen Clients and translates them into operations on databases on the server machine. This enables clients to connect to databases that are located on different machines, potentially running a different platform and operating system bit level. You can install the TimesTen Client on a separate or the same machine as the TimesTen Server. If you install the TimesTen Client on the same machine as the TimesTen Server, you can use them to access TimesTen databases on the local machine. For example, this is useful when you want a 32-bit application to access a 64-bit database on the same machine, for platforms that support both 32-bit and 64-bit applications. Note: Figure 2-1 demonstrates how the TimesTen Client and TimesTen Server communicate using their respective drivers. Figure 2-1 Diagram of TimesTen Client and TimesTen Server TimesTen Client: To access TimesTen databases on remote systems, link your application with the TimesTen Client ODBC driver. The application then communicates with the TimesTen Server process. Using the TimesTen Client driver, applications can connect transparently to TimesTen databases on a remote or local system that has the TimesTen Server and Data Manager installed. You can link a client application either directly with the TimesTen Client driver or with the Windows ODBC driver manager. TimesTen supplies a driver manager for Windows with the Quick Start sample applications. Note that there are performance considerations in using a driver manager. TimesTen Server: On the server machine, the TimesTen Server is linked with the TimesTen Data Manager ODBC driver. The Server's responsibility is to listen for requests from a client application, process the request through the Data Manager ODBC driver, and then send the results and any error information back to the client application. Note: The following sections describe the restrictions and the communication protocols for client/server communication: The following are the restrictions on client/server communication: XLA cannot be used over a client/server connection. On UNIX, some TimesTen utilities only work over direct connections, such as The You cannot connect with an external user defined on one host to a TimesTen data source on a remote host. There are no restrictions for connecting with internal users. Internal users can only be created or altered over a direct connection and not over a client/server connection to a TimesTen database. Thus, you can only execute the On UNIX, TimesTen does not allow a child process to use a connection opened by its parent. Any attempt from a child process using By default, a server process is spawned at the time a client requests a connection. By setting the The following sections describe the communication protocols that the TimesTen Client can use with the TimesTen Server: By default, the TimesTen Client communicates with the TimesTen Server using TCP/IP sockets. This is the only form of communication available when the TimesTen Client and Server are installed on different machines. If both the TimesTen Client and Server are installed on the same machine, applications using the TimesTen Client ODBC driver may improve performance by using a shared memory segment for inter-process communication (IPC). Using a shared memory segment allows for the best performance, but consumes more memory. To use a shared memory segment as communication, you must Configure the server options to use shared memory communication in the Define the Network Address as Note: On UNIX platforms, if both the TimesTen Client and Server are installed on the same machine, you can use UNIX domain sockets for communication. Using a shared memory segment allows for the best performance, but greater memory usage. Using UNIX domain sockets allows for improved performance over TCP/IP, but with less memory consumption than a shared memory segment connection. To use domain sockets, you must define the Network Address of the logical server as Note: The following sections describe how to connect a TimesTen application to a TimesTen database using TimesTen Client and Server: Before the client application can connect to a TimesTen database, the user must configure, as shown in Figure 2-2, the Client DSN, optionally a logical server name, and a Server DSN to uniquely identify the desired TimesTen database. Figure 2-2 Configuring for a client/server connection The client application refers to the Client DSN when initiating a connection. With the following details, the connection request is resolved to be able to connect to the intended TimesTen database: The logical server name is an optional configuration on the client. When used, it specifies the server host name where the TimesTen database is installed. This is used when you want to hide or simplify the server host name. You must use the logical server name when using shared memory IPC or UNIX domain sockets. The Client DSN is configured in either the user or system The Server DSN is configured in the system Thus, when these are configured correctly, the client application can use the Client DSN to locate and connect to the TimesTen database. The Client DSN defines the server machine and the Server DSN. The Server DSN, in turn, specifies the TimesTen database on that server, how the database is to be loaded, and how connections are to be managed. The following sections describe what you must install on which node for client/server connections: The following sections describe how to install and configure TimesTen when the Client and Server are of the same TimesTen release: Perform the following tasks on the machine on which the TimesTen database resides. This machine is called the server machine. Install the TimesTen Server. For information on how to install the TimesTen Server, see the Oracle TimesTen In-Memory Database Installation Guide. Create and configure a Server DSN corresponding to the TimesTen database. See "Defining Server DSNs". Set TimesTen connection attributes in the Server DSN. See "Connection Attributes" in the Oracle TimesTen In-Memory Database Reference. Perform the following tasks on the machine where the client application resides. This machine is called the client machine. Install the TimesTen Client. For information on how to install the TimesTen Client, see the Oracle TimesTen In-Memory Database Installation Guide. If you are using JDBC to connect to the database, install the Java Developer's Kit (JDK), where the Java application will be running and set up the environment variables, such as Create and configure a Client DSN corresponding to the Server DSN. See "Creating and configuring Client DSNs on UNIX" and "Creating and configuring Client DSNs on Windows". For OCI and Pro*C/C++ client/server connections, configure the application to use either Link client/server applications as follows: Link C and C++ client/server applications as described in "Linking options" in the Oracle TimesTen In-Memory Database C Developer's Guide. Link OCI or Pro*C/C++ applications in the same manner as any OCI or Pro*C/C++ direct connect applications, which is described in "TimesTen Support for OCI" and "TimesTen Support for Pro*C/C++" in the Oracle TimesTen In-Memory Database C Developer's Guide. A TimesTen Client can connect to a TimesTen Server from a different release and of a different bit level. A TimesTen Client 7.0 or later release may connect to a TimesTen Server 7.0 or later release of any bit level. If you are configuring for a cross-release TimesTen Client/Server connection, install and configure as directed in "Configuring Client/Server of the same TimesTen release". The TimesTen Server loads a driver and a TimesTen database of its own release and bit level when a TimesTen Client application connects to the TimesTen database. The TimesTen Data Manager is automatically installed on the Server system. If you are using a local client/server connection using UNIX Domain sockets through If you are using a local client/server connection over a shared memory IPC using Server DSNs identify TimesTen databases that are accessed by a client/server connection. A Server DSN must be defined as a system DSN and has the same configuration format and attributes as a TimesTen Data Manager DSN. For a description of DSNs and instructions on creating them, see "Creating a Data Manager DSN on Windows" or "Creating a Data Manager DSN on UNIX". Note: Because a Server DSN identifies databases that are accessed by a TimesTen Server, a Server DSN can be configured using the same connection attributes as a Data Manager DSN. In addition, there are connection attributes that are only allowed within the Server DSN specification. These attributes enable you to specify multiple client/server connections to a single server. Note: For a description of the TimesTen daemon options see "Managing TimesTen Client/Server options". The following sections describe the Server DSN attributes in the context of the Note: By default, TimesTen creates only one connection to a server per child process. However, the following Server connection attributes enable you to specify multiple client/server connections to a single TimesTen Server: Note: The Connection 1 arrives at the server, the first server process is started for this connection. Connections 2 through 5 arrive at the server, server processes 2 through 5 are initiated where each server process services a connection. Connection 6 arrives at the server. Since Connection 11 arrives at the server. Both If you anticipate having more than one connection using the Server DSN, specify appropriate values for the Server DSN attributes as needed. On Windows in the ODBC Data Source Administrator, these are specified on the Server tab. Figure 2-3 Server tab in TimesTen ODBC Administrator A logical server name is a definition for a server system on the TimesTen Client. In some cases, such as when using a communication protocol other than TCP/IP for local client/server or the TimesTen Server process is not listening on the default TCP/IP port, you must define a logical server name on the client system. In these cases, the Client DSN must refer to the logical server name. However, in most cases when the communication protocol used is TCP/IP, the Client DSN can refer directly to the server host name without having to define a logical server name. The following sections demonstrate how to define a logical server name on Windows or UNIX platforms: To create and configure a logical server name: On the Windows Desktop from the Start menu, select Settings, Control Panel, Administrative Tools, and finally Data Sources (ODBC). This opens the ODBC Data Source Administrator. Click User DSN or System DSN. Select a TimesTen Client DSN and click Configure. If no Client DSN exists, click Add, select TimesTen Client 11.2.2 and click Finish. This opens the TimesTen Client DSN Setup dialog. Click Servers. This opens the TimesTen Logical Server List dialog. Click Add. This opens the TimesTen Logical Server Name Setup dialog. In the Server Name field, enter a logical server name. In the Description field, enter an optional description for the server. In the Network Address field, enter the host name or IP address of the server machine. The Network Address must be one of: In the Network Port field, TimesTen displays the port number on which the TimesTen Logical Server €ÿlistens by default. If the TimesTen Server is listening on a different port, enter that port number in the Network Port field. For example: Click OK, then click Close in the TimesTen Logical Server List dialog to finish creating the logical server name. On the Windows Desktop on the client machine from the Start menu, select Settings, and then select Control Panel. Double click ODBC. This opens the ODBC Data Source Administrator. Select a TimesTen Client DSN and click Configure. This opens the TimesTen Client DSN Setup dialog. Click Servers. This opens the TimesTen Logical Server List dialog. Select a server name from the TimesTen Servers list. Click Delete. Define logical server names in a file named by the The Network Address must be one of the following: TimesTen searches for the logical server in this order: In the file specified by the In the Example 2-1 Defining a logical server name This example from a Example 2-2 Using UNIX domain sockets for communication If both the client and server are on the same UNIX machine, applications using the TimesTen Client ODBC driver may improve performance by using UNIX domain sockets for communication. The logical server name must also define the port number on which the TimesTen Server is listening so that multiple instances of the same version of TimesTen Server can be run on the same machine. To achieve this, the logical server name definition in Example 2-3 Configuring shared memory for inter-process communication If both the client and server are on the same machine, applications can use shared memory for inter-process communication. This may result in the best performance. The logical server name must also define the port number on which the TimesTen Server is listening in order to make the initial connection. To achieve this, the logical server name definition in TimesTen uses the To override the name and location of this file at runtime, set the You can define short-hand names for TimesTen Servers on UNIX in the Table 2-1 TimesTen Server format in the TTCONNECT.INI file [ Logical server name of the TimesTen Server machine Description of the TimesTen Server The DNS name, host name or IP address of the machine on which the TimesTen Server is running. The TCP/IP port number where the TImesTen Server is running. Default for TimesTen release 11.2.2 is 53385 for 32-bit platforms and 53389 for 64-bit platforms. For example, the server specification for a remote TimesTen Server might appear as: For a local TimesTen Client/Server application that is using UNIX domain sockets, the network address must be defined as For a TimesTen Client/Server application that is using a shared memory segment for inter-process communication, the network address must be defined as A Client DSN specifies a remote database and uses the TimesTen Client. The Client DSN can be defined as a user or as a system DSN. A Client DSN refers to a TimesTen database indirectly by specifying a Note: Alternatively, you can configure connection attributes at runtime in the Note: The following sections describe how to create the Client DSN and its attributes on either the Windows or UNIX platforms: On Windows, use the ODBC Data Source Administrator to configure logical server names and to define Client DSNs. This section includes the following topics: To define a TimesTen Client DSN: On the Windows Desktop from the Start menu, select Settings, Control Panel, Administrative Tools, and finally Data Sources (ODBC). This opens the ODBC Data Source Administrator. Choose either User DSN or System DSN. For a description of User DSNs and System DSNs see "Specifying Data Source Names to identify TimesTen databases". Click Add. This opens the Create New Data Source dialog. Choose TimesTen Client 11.2.2. Click Finish. This opens the Oracle TimesTen Client DSN Setup dialog. In the Client DSN field, enter a name for the Client DSN. The name must be unique to the current list of defined DSNs on the machine where the client application resides and can contain up to 32 characters. To avoid potential conflicts, you may want to use a consistent naming scheme that combines the logical server name with the name of the Server DSN. For example, a corporation might have Client DSNs named In the Description field, enter an optional description for the Client DSN. In the Server Name or Network Address field, specify the logical server or network address of the server machine. The name can be a host name, IP address or logical server name. The logical server names defined on the client machine can be found in the drop-down list. To define logical server names, click Servers. If you do not specify a logical server name in this field, the TimesTen Client assumes that the TimesTen Server is running on the default TCP/IP port number. Therefore, if your Server is running on a port other than the default port and you do not specify a logical server name in this field, you must specify the port number in the ODBC connection string, using the For more information on defining logical server names, see "Creating and configuring a logical server name on Windows". In the Server DSN field, enter the Server DSN corresponding to the database that the client application will access. If you do not know the name of the Server DSN, click Refresh to obtain a list of Server DSNs that are defined on the machine specified in the Server Name or Network Address field. Select the Server DSN from the drop-down list. You must have a network connection to the machine where the TimesTen Server is running. For more information about customizing which Server DSNs show in this list, see "ODBC Data Sources". In the Connection Character Set field, choose a character set that matches your terminal settings or your data source. The default connection character set is If you are using automatic client failover, you would configure the Failover Server Name, Failover Port Range, and Failover DSN. For details, see "Configuring automatic client failover". You can define the user name, password and timeout interval for the client/server connection in the Client DSN with the For a description of the To set the timeout interval and authentication: In the User ID field of the Oracle TimesTen Client DSN Setup dialog box, enter a user name that is defined on the server machine. In the Password field, enter the password that corresponds to the user ID. Alternatively, you can enter an encrypted password in the PwdCrypt field. In the Timeout Interval field, enter the interval time in seconds. You can enter any non-negative integer. A value of 0 indicates that client/server operations should not time out. The default is 60 seconds. The maximum is 99,999 seconds. Click OK to save the setup. In this example, the TimesTen Client machine is Note: On the server machine Using the procedure in "Defining Server DSNs", verify that the Server DSN, On the client machine, In the Server Name field, enter In the Network Address field, enter In the Network Port field, enter See "Creating and configuring a logical server name on Windows" for the procedure to open the TimesTen Server Name dialog and for more details. On the client machine, In the Client DSN field, enter In the Server Name or Network Address field, enter In the Description field, enter a description for the server. Entering data into this field is optional. In the Server DSN field, enter Run the client application from the machine This example describes how to access a TimesTen Server that is listening on a port numbered other than the default port number. Consider that the Network Address of the TimesTen Server is Define the logical server name Alternatively, define the logical server name Alternatively, define the Server in the connection string. In this case you do not need to define a Client DSN, nor a logical server name. To test client application connections to TimesTen databases: On the Windows Desktop from the Start menu, select Settings, and then select Control Panel. Double click ODBC. This opens the ODBC Data Source Administrator. Select the TimesTen Client DSN whose connection you want to test and click Configure. This opens the TimesTen Client DSN Setup dialog. Click Test TimesTen Server Connection to test the connection to TimesTen Server. The ODBC Data Source Administrator attempts to connect to TimesTen Server and displays messages to indicate if it was successful. During this test TimesTen Client verifies that: ODBC, Windows sockets and TimesTen Client are installed on the client machine. The server specified in the Server Name or Network Address field of the TimesTen Client DSN Setup dialog is defined and the corresponding machine exists. The TimesTen Server is running on the server machine. Click Test Data Source Connection to test the connection to the Server DSN. The ODBC Data Source Administrator attempts to connect to the Server DSN and displays messages to indicate whether it was successful. During this test, TimesTen Client verifies that: The Server DSN specified in the Server DSN field is defined on the server machine. A client application can connect to the Server DSN. On UNIX, you define logical server names by editing the Note: In the ODBC Data Sources section of the ODBC client driver to use for the connection. The server machine on which the database resides on is specified in the The Server DSN that specifies the intended database is specified in the Note: For each TimesTen database with which the client will connect needs to have two entries: Define the Client DSN name and provide the name of the ODBC client driver to use in the ODBC Data Sources section. Create an entry with the Client DSN you defined in the ODBC Data Sources section. Within this section, specify the server machine and the Server DSN. The following is the syntax for providing the Client DSN name and the ODBC client driver to use: For example, to defined After the ODBC Data Sources section, you would add an entry to specify the server machine and Server DSN for each data source you defined. Each Client DSN listed in the ODBC Data Sources section of the The following is an example specification of the TimesTen Client DSN The Automatic client failover is for use in High Availability scenarios with a TimesTen active standby pair replication configuration. Consider a scenario where failure of the active TimesTen node has resulted in the original standby node becoming the new active node. With the automaticTø« client failover feature, failover (transfer) to the new active (original standby) node occurs, and applications are automatically reconnected to the new active node. TimesTen provides features that enable applications to be alerted when this occurs, so they can take any appropriate action. Note: The following sections describe how to use and enable automatic client failover: When an application connects to the active node, the connection is registered and this registration is replicated to the standby node. If the active node fails, the standby node becomes the active node and then notifies the client of the failover. At this point, the client has a new connection to the new active node. No state from the original connection, other than the connection handle, is preserved. All client statement handles from the original connection are marked as invalid. When failover completes, TimesTen makes a callback to a user-defined function that you register. This function takes care of any custom actions you want to occur in a failover situation. Note: For Java developers, details are discussed in "JDBC support for automatic client failover" in the Oracle TimesTen In-Memory Database Java Developer's Guide. The following items list the behavior of automatic client failover in particular failure scenarios: If the client library loses the connection to the active node, it will failover and attempt to switch to the standby node. If, for some reason, there is no active node (no failover has occurred at the server side and both servers are either standby or idle), applications cannot connect. But automatic client failover continues to alternate between both servers until it finds an active node or times out. If a failover has already occurred and the client is already connected to the new active node, the next failover request results in an attempt to reconnect to the original active node. If that fails, alternating attempts are made to connect to the two servers until it times out. Note: This timeout defaults to 60 seconds or can be set with the value of the If the active node fails before the client registration is successfully propagated by replication to the standby node, the client will not receive a failover message and the connection registration will be lost. However, the client library will eventually notice (through TCP) that its connection to the original active node has been lost, and will then initiate a failover attempt. Notes: These features apply only to client/server connections, not direct connections. Failover connections are created only as needed, not in advance. Using automatic client failover results in one additional database connection per server process, which should be considered as you choose a setting for the TimesTen You can configure automatic client failover for databases that have active standby pair replication schemes. This enables the client to fail over automatically to the server on which the standby database resides. Note: In the Oracle TimesTen Client DSN Setup dialog, after you have configured the rest of the Client DSN information as described in "Creating and configuring Client DSNs on Windows", complete the following fields: In the Failover Server Name or Network Address field, specify the logical server or network address of the server machine. The name can be a host name, IP address or logical server. The logical server names defined on the client machine can be found in the drop-down list. To define logical server names, click Servers. If you do not specify a logical server name in this field, the TimesTen Client assumes that the TimesTen Server is running on the default TCP/IP port number. Therefore, if the Server is running on a port other than the default port and you do not specify a logical server name in this field, you must specify the port number in the ODBC connection string, using the For more information on defining logical server names, see "Creating and configuring a logical server name on Windows". In the Failover Server DSN field, enter the Server DSN corresponding to the standby database. If you do not know the name of the Server DSN, click Refresh to obtain a list of Server DSNs that are defined on the machine specified in the Failover Server Name or Network Address field. Select the Server DSN from the drop-down list. You must have a network connection to the machine where the TimesTen Server is running. Optionally, specify the Failover Port Range for the port or port range where TimesTen listens for failover notifications. By default, TimesTen uses a port chosen by the operating system. To accommodate firewalls between the client and server systems, you must specify one value for a UDP port number or a range of UDP port numbers. A port range is set as a lower and upper value separated by hyphen. On the client, configure the following: In the For example: Configure the following connection attributes for the logical server DSN in the Setting any of You intend to use automatic client failover. You understand that a new thread will be created for your application to support the failover mechanism. Optionally, configure the Notes: Like other connection attributes, If If the client library cannot connect to The TimesTen Server is a child process of the TimesTen daemon. If you installed the TimesTen Server, this process is automatically started and stopped when the TimesTen daemon or Data Manager service is started or stopped. You can explicitly start or shut down the daemon or service with the The TimesTen Server handles requests from applications linked with the TimesTen Client driver. The default ports for the 32-bit and 64-bit versions of TimesTen main and TimesTen Servers are described in the "TimesTen Installation" chapter in the Oracle TimesTen In-Memory Database Installation Guide. System administrators can change the port number during installation to avoid conflicts or for security reasons. The port range is from 1 - 65535. To connect to the TimesTen Server, Client DSNs are required to specify the port number as part of the logical server name definition or in the connection string. On Windows, the TimesTen service is run as user For instructions on modifying TimesTen Server options, see "Modifying the TimesTen Server options". In this example, the TimesTen Client application machine is a 32-bit Solaris machine, On the server machine Verify that the Server DSN There should be an entry in the Create a logical server name entry for the remote TimesTen Server in the See "Creating and configuring Client DSNs on UNIX" for information on the creating a On the client machine, There should be an entry in the See "Overview of user and system DSNs" for information on the location of the proper Run the client application from the machine The next example describes how to access a TimesTen Server that is listening on a port numbered other than the default port number. Let us consider the Network Address of the TimesTen Server is Define the logical server name Alternatively, define the logical server name Alternatively, define the server in the connection string. In this case you do not need to define a Client DSN, nor a logical server name. To test client application connections to TimesTen databases: Verify that the client machine can access the server machine. Run Verify that the TimesTen Server is running on the server machine. Use If you successfully connect to the TimesTen Server, you will see a message similar to: If the server machine responds to a command, but TimesTen Server does not, the TimesTen Server may not be running. In the case of a failed connection, you will see a message similar to: Use the Verify that the client application can connect to the database. If you cannot establish a connection to the database, check that the If the information in the <á“ß!ÉòŽûÍüÅž¤ÝÕáI_9Í€ŒS èÁ þÏöm’ùš öŒø ù%àL TBõC…ž% ÌT`Œ\ ûÅ_¤÷Ô þSì_˜àÿ}š§Y Û»E.[””ß*me]!’”eýëE ΊÛüÑžôå_8 t€ äACøß%ÖY³aPAœ©‹P!ðÉúñDû
žË 5ˆÄ :
ìß º!÷ýœ'±YašÆÑœž¥ •èá ÎÅêaDëaÞë¢Õ-\÷4H èŸ ôÁ œâA0"
¢—”- ÝÑ Î[$ o`b&¶Å&^D'²_æ"ÛùXô±@ìÁþé Ì °b .Yþ+¢ -Nb4ÆÑ%Â`.>Æ.ZD/úá/6Ÿ¡çA@)B@ ìß &!åÜ NÜ &Æ5›Îå¡5^c‹à Ûè`À^ Î^¥‚ ØÁ85À àAB¤£¯ Χ} %™’ÎÌÙ\%U"Ïu.ÚcLá#é#?†âËUK t ¤†@€È@Œ“Ÿäߟœ èe¤FfE6VÄ6^7f`?
ßBtIž$EØ ÛÉäLŠG¦‘G#ç1—ø$Pš¤¯, U2 ðåQZJR2ÒRzãN’^° ä_Pf¥]µ‰w™%Sm¥+U ì#S>ŸS~ŠXÄOJþ¥ZN“?æ¥.²%1¹%\z%H
¢HêÇ]â%_– O&¦\Ô$EÜ$N¼åGãÕQK]’ÅO–%cŽ n& ^ž/Jf\Êß\þã~d&bò%VzfL8æD@fˆ¦`R¦(Z&ejªåj²fK¸¦DÀ¦lêä`îåž\æ~hfªf=ò¦UøfD g`
'm†¤mîÇAÌ IææLî&sª„sBtNfS¶]OZ§Aø‰ D¥rgwJÅw>DxŽæŽ¡iêÇA §zæ%w¶çI¼§CÄçlŽ§0>¥}BÀŸä_9uÁz.&R…j`Š§\’'„ü Pf¨‚êçr6(S
úÒ¡ u©û´é(ÇõÔ±žuÇzÖ&w·Ó¯¾u±ì —B× ö²¯ímÏ ~r[?Ýíu·ûÝáîõ~Óýî}÷»Øݤ÷: ~ðÅæûߟx¥cP&‚'| ¯vÅOžòBg|ãaûxÈ÷üç•÷üçë½É7Vó‘?6èQŸzkû2˥缼U {Ùsšõ–výágŸ{Ý'¸ö™¼é©½{áê¬íÿúqŸùͧ®ñ³»Y $ ÷ηþõ) :H!ú
˜>á/î‘cŸüå×y
¶ß} |óÕ7ÿûá/\þ:¤¿¸Ò_á•?þøïŸÿ„F?ýaký0üâmùúï ðŽÞÀæ/ýP 1€ ÿ
ö°-0Øpþ² #0ÿ.ðAÚ2P p =0Q0·cpþJpý$Ðç(Pi°!‚[ð;Ðýl°CPc°ó|°m]°°8pgÐð‘„ðŸ°
S0
§p É •™Ð ¹p áÏ íϵ ÕPøÌ°r ©p
åÐüÚðà0
ç0Q¯ßãP‘øêðú0 õ/ïF0 7ëñ
1%Q÷ÑwPò&1)¯ þ15ñ?/ÀA±OIÑU±ïPñWñÙ®ñiÑòQ
Ëu1k±µN1Ñ…1é€ñô†ñïaK;Ñ‘ñ®ƒ©1•1™‘«qÓMÅÁ‘Þ¼± 1 ÍQÄÆqÅð ÙñÓÒQ×± å±ÑÚÐìÑ µq õÒêñ - ÷1 û¬ ï ò Œ ñѲ!‰î7Ë ÿ‘! ²"çK!- (Ò"9¼0R#g±#E²²>r#Gò$q«$C%Yò¨T2[2&³"@"A&e2'çê%Q'}’±´/ Ë&Mò'þR¥‚2‡Ò o²'ò)q*)±&™²(¡ò*ý«q1"«r%±ò+)íÿ”’+ï±)§,Ñ2Ö´¶ˆÒ+Óò-—D*·’*ËÒ*áò.In-—².Ý/ýòíÄr*Û'ÿ²0ã20çr0Ò0“Mä’-»’0s2S/ÉÒ Íò)s3#ä1÷3í’3Eóz,“.A³/G“2=ó2324Só5b5M³5Ñçló6q37us7y³7}ó7WN63Ñ€³8ó8‘39•s9™9…32 G§¤s:©³:ó:±3;µs;¹³;½ó;Á3<Ås<ɳ<Íó<Ñ3=Õs=Ù³=Ýóþ=á3>ås>Ãó9ù²4š3?õs?ù³?ýó?—Ó>O6 4@”6 4AQã@3SA Ô%´ç tB "B)ôBIS(Y³A1´C!ÀB=4D1!ó>EÔCA”±Z€X´E]ôEa4FetFi´FmôF[´tçÖªG}ôGÉêvH‰´HTH)‡GtI™4Hw-E犬€‚ ô> À
X q$à’ªJ—ê$@K¹ÔKíÃÀTL»”L3ÂLÃôÕ6i,g“C*KËQµ Ku&Ú¼¤b¤–DOëÔ§ú4q •O ÀOÝѵ:£4PU OÃ%*ÄkH"ÕQQþDRËRW-œ“QåŠ,µ§ RùDSùSU©‹SÙ„U;MU#M³âTB{JT'ÕT_uTqÊUÿ”W-KVwV›ËW•¸ê¯V W7UWuR…7ˆ•¹Œ5S5¥ªuÓ OÀ†3T¯5¡J•P¥‚Gȵ\£#ZQDÌu]Ùõ+²u;Ôµ]åµ]ß• ±§ûºõª˜õ€à _ÛŠ þu VÐœ5Bâ•\ad^›ã\ÅÕ\)-v,è]Oã`×µ86båµ^é{¸/Yóõ¨öÕz6`MÖ¹
ÖZ/v+Ö\96]Ça[$,4vfk6-^¶bc¶]1–fç5,rÐþÆdAU_¿õ V`•’–`¶\{–g]–bóÂbŸ#jI„-VdjŸV^±Ö8~,‚v =–ûJt@kd)§iÿµšÖiótgw¤9–F^dFêöfÑbl—ÂjköFðVDìVoÅ‚oKInWvf]¤FB¤pö-¨–lWÃÒBvN`¢mßn#_ü§UÜ'Låkêuüž2tC÷`&`HWuܧTwUY·u_e„L·TöwiG×ç34m3wi‘Vi;7qÂ5Oowg÷GðGtåÇw ¥váµy[wlv7U #z?wwX±—zIg{G‡|×MËÖþr‹Vd‹—i7wi“7\–÷sÑwt§÷jüz¿·uÃWZÇ×´wSº÷uÅF©÷Ó5€©w€-¥€w}/x×÷l‡·Qù5~á×xÓ+em÷~¥7vØs\7t¸b˜ 8tÌWg—N¸jSØy¥·
X‚[%†)Wƒ”•±Ôvm—ƒç—¿<øz%X„Øt‘Øwu¸ogØu¨f F„Kuiwr‡]·…³æ…™‹Ñ±‚…WN}ê‡×Ö_ƒXs;˜PŸøu
˜€YaøŽI|Áø(ØÇw)e»¸kfU8ï8(ò‡ øMçµx‚Õ·r-˜Œoõ}¯©~OþÜé’©‰KÉ’1¹“ùH“ñ˜“=9Š”¨@¹øÄxCm§Ìx¹(ùUEy”eyŠ9by–q9 NÙ–sÙ‰J™vÙÁ‚W•—U’é•ÿô–{y”ƒ™%Ôi™™¹–¡B™—ù—ש™‰.•{˜xs•¡—±j¨ù›Ý)œ#â™Éù’͹¾†y›1¸Y½9=y 嘥ٙÇùž›‰ž/R›/·Œ)ˆOï”Pê£:¡Ú¢B*Ÿƒã :¢%ú£Ú j¢1:£Z¤(Ø‘Çx•UJJ©TM3âJ‹x7tŠ§n ¨Ú4\R¼XZKw
¦ƒª‘y8 ËGuz§yº§þuZw²ªI…z¨Ù
¨‰ú¨›tˆ·#¨‘º©T©;Ö£‰ùDQ Û—ª ´q« T«¯š« Ô«M¬ T¬Ñ–¬³Úªí± GS¬+€AÚ7Ó«ãZ®é:¥š*` ;°°¹ °
û°{°{±»± û±!;²%{²)›± ¼à 4{³¿ <û³?; D[´Å ´Mû´Å` T{µY»µ]ûµa;¶_› h»¶mû¶q;·u{·y»·}û·k» ÊÀ ÎÀ°
;¹•{¹Ñ`°
Û ;º¥{º©Û „ûº±;»µ{»±»º½û»Á{ºa;
È»¼Íûþ¼Ñ;½Ï[
Ø»½Ýû½ß{
ä{¾é»¾é›
ð;¿ñ; ÚÀ
üû¿<À|À ¼À
<Àß Á|Á¼Á üÁ!<Â%ÜÁ9àözãšh ädŒ<üÃA<ÄE|ÄI¼ÄMüÄQ<ÅU|Äe
¬àů Æe|Æg lüÆq<Çq † %¯\ev\‡¯„|ȉ¼ÈüÈ‘¼ÈmÌÄk ɼÉGüÉ’œÈ?n¬üʱÜÊ5zË
¼üËÁ<b`ÅɼÌÍüÌÏüÉÕ|ÍÙ¼Ío@öº0ü®é¼ÎíüÎñ\Î%rÏù¼Ïýܘ1Ð}Ð ½Ð =Ñ}Ñ×/ ÝÑ5þ`8 <À> B D`ÓE <ýÓA`D}ÔG€J L ÕSýXýRàÕU Ö_´V”\àÖq=×qÖyý|ý× Ì…]ÌcÀ£ˆýØ‘=ÙÇ Í™}Ä›Ün€p r@ A°=ÛsÂÑs * (àlÀÚ¼ÜÍýÜÑ=ÝÕ}Íy ÝÝýÝß½zÀèÝ~àÞ€
€`ßù߃àß à…`à ¾à
žˆ ~á‹ áàá!ÞŽ`â)¾â 0 ã•`ã£@Û=þãA>äE~äI ä»îäQ>åU ÅfbØl‚(Àò|æiÞÎÿüæq^"þ
}çy¾çu‘Ñ>èðÑ ý $Ò?à2]Ó7=@ýÓI}ÔM ÕUÝZýP b=ÖW GkÝÖu=ì]€×i Ø]ØÃ\ÌZÙ•½ÙÝ^ÄŸ=Ú§½Ú¯½äu"t Û¿=ÜÇ}Ýýþï?ðk Þ _ÞëÞñýú}ñ¾ñƒÀà!à‡@žáÞá#þá-Þâ3 ã“@ ¢` ì~ôI¿ôMßãW>õUŸå¥ ¦À " æiæe>çq ç}~÷y?Ð…þ÷è5Àè; é1=Ó9ÝéŸ>Ô£¾ÔO½ê¾Õ³^´^º>G]Tìuì[Àìƒ í½\í#šþØþíÍ?Äk`Ü£ÚuÀÚ3€ô =ï3œïÉ]ðœÌí?ÿŸœðã}Þ?ñˆÀƒ
"’ücÿ þ`Ä?, “ðà Gðˆ'Db¸ø‹#¼@C7T÷DâG@ì?pæŒ~Db9ýûÇq‹H|Á¥»ŒñÄâh¤@¸)0Až‘Là %XA$ÈA
pø n ‚+ú0 Ì‚ËDÖà7øú«èF]0‹t¢ðH û)ø®ÅlIr!ht¤sðG;4À´Ž°¡ û€ÚºÐ9Ì¡¼ô-‚ÚPôO
€ÈE!´Ð9ñVÃzñmXüˆ"„¸ºÃD°•Mà
Pç#DÊ´}Ô5ˆKs ä6 UÔõþ°À?Ð 9$ˆ
(
PÀ %¸€ œ5ü‡ DR)È€ €" &´ Vhð/Xž*`B|(ZØÂŽÀ¡ŽH hRª‹!L€Å!Bÿ¤iC;s€YP ƒy¸‚0‚W8:‚0"Ø—@mè„10U¾ÇJ‚ÙË„Fø‡8˜Œ’XH3‚ 5G„DAÖëD‚ð¨>¸‡Cø;È” P‚x^à÷JÔ Úú ¨dðŽ .Ø[¡M|8O<Æ—ƒ\#ˆ X8Jh%)ˆ…êû" €64 _p¯'è´AÈE wøNÀ‡°9ƒZ`AbTNDƨ» M €ÿ∠‚x… #RP<0 `’ÇÚ Ðpoìˆ+P¶p…°‘‚=ȃÜIÈNYGvl¸ÿ zð px„0àˆ1Ø…tðˆ ¨o q „Íy,}ˆ„HðOðŠ´¬¯[ƒ>ð€" ’XJHÇt±È‹$¶º0B(°:uògQ’ÅI ÐG2DLÈ‚,ø‚ˆ Ÿ$ˆ{ø„)60D¿Q€- žŸ4Æè0\H ô ?¨„Ž£Nc¹À¨é´§ê´3Ñ·À"~ày.H™¥¸Éf@ËŠTKè¸8x˾ "X80YDìù“²Ž`ƒP$ˆ`ªÑÉ
Connection Character Set: AL32UTF8
NLS_SORT: BINARY
NLS_LENGTH_SEMANTICS: BYTE
Server Name: ttlogical_server
Description: TimesTen Primary Server
Network Address: server.mycompany.com
Network Port: 53385
PKH wä ß PK \8–A OEBPS/img_text/jdbc_steps.htm~û
Put plans into the PLAN table. ttOptSetFlag
Prepare command. Connection.prepareStatement
Examine PLAN table. SELECT * FROM SYS.PLAN
Set various optimizer hints. ttOptSetFlag
Prepare command again. Connection.prepareStatement
Examine PLAN table. SELECT * FROM SYS.PLAN
Logging: 1-Disk Logging
Log Flush Method: 0-Platform Default
Auto Create
Log Auto Truncate
Log Purge
Set various optimizer hints. ttoptSetFlag
Prepare command. Connection.prepareStatement
Execute command. Statement*.execute*
Execute command. Statement*.execute*
Command is invalidated (if application shooses to invalidate). ttopUpdateStats on T2
Command is reprepared automatically, using same hints, and executed. Statement*.execute*
Execute command. Statement*.execute*
Drop command. PreparedStatement.close
Set various optimizer hints. ttOptSetFlag
Prepare command. SQLPrepare
Execute command. SQLExecute
Execute command. SQLExecute
Command is invalidated (if application chooses to invalidate). ttOptUpdateStats on T2
Command is reprepared automatically, using same hints, and executed. SQLExecute
Execute command. SQLExecute
Drop command. SQLFreeStmt
Data Source Name: TempDS
Description
Data Store Path +: C:\data\TempDS
Log Directory: C:\temp
Database Character Set: US7ASCII
Type Mode: Oracle
Data Source Name: AdminDSN
Data Store Path +: C:\data\TTDS
Log Directory: C:\Temp
Database Character Set: AL32UTF8
Type Mode: 0-Oracle
Put plans into the PLAN table - ttOptSetFlag
Prepare command - SQLPrepare
Examine PLAN table - SELECT * FROM SYS.PLAN
Set various optimizer hints - ttOptSetFlag
Prepare command again - SQLPrepare
Examine PLAN table - SELECT * FROM SYS.PLAN
Level 3:
TblLkRangeScan (Step 1)
RangeScan (Step 2)
Level 2:
MergeJoin (Step 3)
TblLkRangeScan (Step 4)
Level 1:
MergeJoin (Step 5)
Connection Character Set: US7ASCII
NLS_SORT: BINARY
NLS_LENGTH_SEMANTICS: BYTE
Client DSN
Description
Server Name or Network Address (set to ttlogical_server)
Server DSN
User ID
Password
PWDCrypt
Failover Server Name or Network Address
FailoverServer DSN
Connection Name
Connection Character Set
Network Timeout (in seconds) (set to 60)
Failover Port Range
Connection Character Set: US7ASCII
NLS_SORT: BINARY
NLS_LENGTH_SEMANTICS: BYTE
Data Source Name: GlobalDSN
Data Store Path +: C:\data\TTDS
Log Directory: C:\Temp
Database Character Set: AL32UTF8
Type Mode: 0-Oracle
PKb!oý)
) PK \8–A
OEBPS/toc.ncxV
©ò
8 Transaction Management and Recovery
Transaction overview
COMMIT statement commits the current transaction. Updates made in the transaction are made available to concurrent transactions.ROLLBACK statement rolls back the current transaction. All updates made in the transaction are undone.
COMMIT and ROLLBACK statements, see "SQL Statements" in the Oracle TimesTen In-Memory Database SQL Reference.
Configuring transaction implicit commit behavior
Transaction autocommit behavior
INSERT, UPDATE or DELETE several rows in one call when autocommit is on, a commit occurs after the entire batch operation has completed. If there is an error during the batch operation, those rows that have been successfully modified will be committed within this transaction. If an error occurs due to a problem on a particular row, only the successfully modified rows preceding the row with the error are committed in this transaction. The pirow parameter to the ODBC SQLParamOptions function contains the number of the rows in the batch that had a problem.ttLockWait procedure.
TimesTen DDL commit behavior
COMMIT before and after any DDL statement.DDLCommitBehavior connection attribute, as follows:CREATE, ALTER and DROP statements for any database object, including tables, views, users, procedures and indexes.TRUNCATEGRANT and REVOKEDDLCommitBehavior=0 include the following:ON COMMIT PRESERVE ROWS clause.CREATE TABLE ... AS SELECT statement are visible immediately.TRUNCATE statements are committed automatically. However, the truncate of the parent and child tables must be truncated in separate transactions, with the child table truncated first. You cannot truncate a parent table unless the child table is empty. The truncation of child and parent table can only be in the same transaction if you set DDLCommitBehavior to 1.
Relationship between autocommit and DDLCommitBehavior
DDLCommitBehavior configure if and when implicit commits occur for SQL statements.DDLCommitBehavior is disabled, autocommit only commits after the DDL statement. However, if both autocommit and DDLCommitBehavior is enabled, an implicit commit occurs both before and after the DDL statement.DDLCommitBehavior, you set the DDLCommitBehavior DSN attribute. To enable or disable autocommit, the application executes an ODBC function or JDBC method.
AutoCommit DDLCommitBehavior Relationship
Transaction semantics
If Then Transaction is terminated successfully (committed)
DurableCommits attribute is turned on.Transaction is rolled back
System fails (data not committed)
Application fails
Transaction atomicity
Transaction durability
Guaranteed durability
DurableCommits attribute to 1.
LogFlushMethod first connect attribute to 2. This connection attribute configures how TimesTen writes and synchronizes log data to transaction log files. For more information, see "Use durable commits appropriately".
Delayed durability
DurableCommits attribute to 0. This is the default and the recommended option. Connections that use delayed durability can coexist with connections that use guaranteed durability.
Durable commit performance enhancements
DurableCommits=0. This causes the transactions to commit non-durably.ttDurableCommit built-in procedure before committing. The ttDurableCommit built-in procedure does not actually commit the transaction; it merely causes the commit to be durable when it occurs.
Transaction logging
Managing transaction log buffers and files
LogBufMB DSN attribute. Each transaction log buffer can have multiple strands. The number of transaction log buffer strands is configured with the LogBufParallelism attribute.LogFileSize DSN attribute. The transaction log files are created in the same directory as the checkpoint files unless the LogDir attribute specifies a different location. The transaction log file names have the form ds_name.logn. The ds_name is the database path name that is specified by the DataStore DSN attribute and is provided within the database's DSN. The suffix n is the transaction log file number, starting at zero.
LogDir attribute to place the transaction log files in a different physical device from the checkpoint files. If separated, I/O operations for checkpoints do not block I/O operations to the transaction log and vice versa.
Monitoring accumulation of transaction log files
Purging transaction log files
CkptFrequency connection attribute, a configurable log volume with the CkptLogVolume connection attribute, or execution of the ttCkpt built-in function, which can be called either manually or in a background checkpointing application thread.CkptLogVolume connection attribute instead of the CkptFrequency connection attribute. In addition, if you execute the ttLogHolds build-in procedure frequently, you can tell if log reclamation is blocked.
LogDir connection attribute determines where log files are stored. For more information, see "Managing transaction log buffers and files" and "LogDir" in the Oracle TimesTen In-Memory Database Reference.CkptFrequency and CkptLogVolume. Also, see CkptFrequency, CkptLogVolume, ttCkpt, and ttLogHolds in the Oracle TimesTen In-Memory Database Reference.
Log holds by TimesTen components or operations
AUTOREFRESH: There is a transaction log hold until the replication agent on the active database confirms the log files have been fully processed by the standby database.AUTOREFRESH mode.FAILED through a call, initiated by either the user application or Oracle Clusterware, to the ttRepStateSave built-in procedure. The active database does not take over propagation to the Oracle Database until the state of the standby database is marked as FAILED. While the standby database is down or recovering, transaction log files are held for the Oracle Database.ttXactAdmin utility with the -xactIdRollback option. See "ttXactAdmin" in Oracle TimesTen In-Memory Database Reference.
Monitoring log holds and log file accumulation
ttLogHolds built-in procedure, which returns a result set with details of all log holds. The information includes the following, as applicable:ttCkptHistory built-in procedure to check the last several checkpoints to confirm none of the returned rows has a status of FAILED.SYS.MONITOR table for operational metrics. Each transaction log file has a unique sequence number, which starts at 0 for the first log file and increments by 1 for each subsequent log file. The number of the current log file is available in SYS.MONITOR.LAST_LOG_FILE. The number of the oldest log file not yet purged is available in SYS.MONITOR.FIRST_LOG_FILE. You should raise an error or warning if the difference in the sequence numbers exceeds an inappropriate threshold.SYS.TRANSACTION_LOG_API table that provides bookmark information, such as the process ID of the connected application, which could help diagnose the reason why a bookmark may be stuck or lagging.
Concurrency control through isolation and locking
Transaction isolation levels
SQLSetConnectOption ODBC function with the SQL_TXN_ISOLATION flag set to SQL_TXN_READ_COMMITTED.isolation=1 in the connection string.ttIsql, execute ISOLATION 1 or ISOLATION READ_COMMITTED.SQLSetConnectOption ODBC function with the SQL_TXN_ISOLATION flag set to SQL_TXN_SERIALIZABLE.isolation=0 in the connection string.ttIsql, execute isolation 0 or isolation serializable.INSERT, UPDATE or CREATE VIEW statement that triggered the view maintenance, instead of holding them until the end of the transaction.
ttXactAdmin utility generates a report showing lock holds and lock waits for all outstanding transactions. It can be used to troubleshoot lock contention problems where operations are being blocked, or encountering lock timeout or deadlock errors. It can also be used to roll back a specified transaction.
Locking granularities
LockLevel connection attribute to 0.ttLockLevel built-in procedure with the lockLevel parameter set to Row. This procedure changes the lock level between row-level and database-level locking on the next transaction and for all subsequent transactions for this connection.ttOptSetFlag procedure to set the RowLock parameter to 1, which enables the optimizer to consider using row locks.
ttOptSetFlag procedure to set the TblLock parameter to 1, which enables the optimizer to consider using table locks. In addition, set RowLock to 0 so that the optimizer does not consider row-level locks.
LockLevel connection attribute to 1.ttLockLevel built-in procedure with the lockLevel parameter set to DS. This procedure changes the lock level between row-level and database-level locking on the next transaction and for all subsequent transactions for this connection.
Setting wait time for acquiring a lock
LockWait connection attribute to the maximum amount of time that a statement waits to acquire a lock before it times out. The default is 10 seconds. For more information, see "LockWait" in Oracle TimesTen In-Memory Database Reference.
Checkpoint operations
Purpose of checkpoints
Usage of checkpoint files
dsname.ds0 and dsname.ds1, where dsname is the database path name and file name prefix specified in the database DSN. During a checkpoint operation, TimesTen determines which checkpoint file contains the most recent consistent image and then writes the next in-memory image of the database to the other file. Thus, the two files contain the two most recent database images.dsName.resn files for each database. These files are pre-allocated to the same size as the transaction log files. The .res files contain pre-allocated space that is used if the transaction log directory were to become full. If this occurs, transactions are prevented from writing any new log records. Transactions that attempt to write new log records are forced to rollback.
Types of checkpoints
Fuzzy or non-blocking checkpoints
Transaction-consistent checkpoints
ttCkptBlocking built-in procedure. The actual checkpoint is delayed until the requesting transaction commits or rolls back. If a transaction-consistent checkpoint is requested for a database for which both checkpoint files are already up to date then the checkpoint request is ignored.
Setting and managing checkpoints
CkptFrequency attributeCkptLogVolume attributeCkptRate attributettCkpt built-in procedurettCkptBlocking built-in procedurettCkptConfig built-in procedurettCkptHistory built-in procedure
Programmatically performing a checkpoint
ttCkpt built-in procedure to request a fuzzy checkpoint or the ttCkptBlocking built-in procedure to request a transaction-consistent checkpoint.
Configure or turn off background checkpointing
CkptFrequency and CkptLogVolume connection attributes as follows:CkptFrequency connection attribute controls the how often, in seconds, that TimesTen performs a background checkpoint. The default is 600 seconds.CkptLogVolume connection attribute controls how much data, in megabytes, that collects in the log between background checkpoints. By increasing this amount, you can delay the frequency of the checkpoint. The default is 0.CkptFrequency and CkptLogVolume connection attributes to 0.ttCkptConfig built-in procedure. The values set by ttCkptConfig take precedence over those set with the connection attributes.
Display checkpoint history and status
ttCkptHistory built-in procedure to display the information on the last eight checkpoints. You can monitor the progress of a running checkpoint with the Percent_Complete column.
Setting the checkpoint rate
CkptRate attribute or the ttCkptConfig built-in procedure to set the maximum rate at which background checkpoint data is written to disk. Checkpoints taken during recovery and final checkpoints do not honor this rate; in those situations, the rate is unlimited.
ttCkptHistory built-in procedure.Percent_Complete column of the ttCkptHistory result set, the rate can be increased by calling the ttCkptConfig built-in procedure. If a call to ttCkptConfig changes the rate, the new rate takes effect immediately, affecting even the running checkpoint.ttCkptHistory built-in procedure.Percent_Complete field of the ttCkptHistory call may show 100 percent before the checkpoint is actually complete. The Percent_Complete field shows only the progress of the writing of dirty blocks and does not include additional bookkeeping at the end of the checkpoint.
PKÐÁT¦þñ êñ PK \8–A OEBPS/client_server.htm €ÿ
7 Working with Data in a TimesTen Database
Database overview
Database components
Database users and owners
UID connection attribute in the connection string, TimesTen uses the current user's login name. TimesTen converts all user names to upper case characters.SYS. TimesTen determines the user name by the value of the UID connection attribute, or if not present, then by the login name of the connected user. If a user's login is SYS, set the UID connection to override the login name.
Database persistence
CkptFrequency and CkptLogVolume. TimesTen also checkpoints the database when the last application disconnects. Applications can also checkpoint a database directly to disk by invoking the ttCkptBlocking built-in procedures described in the Oracle TimesTen In-Memory Database Reference.
Understanding tables
Overview of tables
Column overview
NOT NULL, columns are nullable. If a column in a table is nullable, it can contain a NULL value. Otherwise, each row in the table must have a non-NULL value in that column.ALTER TABLE statement. To change column definitions, an application must first drop the table and then recreate it with the new definitions.
In-line and out-of-line columns
VARBINARY, NVARCHAR2 and VARCHAR2 column of a table as either in-line or not inline.VARCHAR2, NVARCHAR2 or VARBINARY data type columns are stored out-of-line. Out-of-line columns are not stored contiguously with the row but are allocated. Accessing out-of-line columns is slightly slower than accessing in-line columns. By default, VARCHAR2, NVARCHAR2 and VARBINARY columns whose declared column length is > 128 bytes are stored out-of-line. In addition, all LOB data types are stored out-of-line. Columns whose declared column length is <= 128 bytes are stored in-line.
Default column values
NULL for any column typeSYSDATE for DATE and TIMESTAMP columnsUSER for CHAR columnsCURRENT_USER for CHAR columnsSYSTEM_USER for CHAR columnsDEFAULT clause of the CREATE TABLE statement but do not specify the default value, the default value is NULL. See "Column Definition" in the Oracle TimesTen In-Memory Database SQL Reference.
Table names
SYS, or TTREP if created during replication.MARY.PAYROLL. If an application does not specify an owner, TimesTen looks for the table under the user name of the caller, then under the user name SYS.
Table access
Primary keys, foreign keys and unique indexes
System tables
Working with tables
Creating a table
CREATE TABLE. The syntax for all SQL statements is provided in the Oracle TimesTen In-Memory Database SQL Reference. TimesTen converts table names to upper case characters.
NameID, with two columns: CustId and CustName of two different data types.
CREATE TABLE NameID (CustId TT_INTEGER, CustName VARCHAR2(50));
Customer, with the columns: CustId, CustName, Addr, Zip, and Region. The CustId column is designated as the primary key, so that the CustId value in a row uniquely identifies that row in the table, as described in "Primary keys, foreign keys and unique indexes". The UNIQUE HASH ON custId PAGES value indicates that there are 30 pages in the hash index. This number is used to determine the number of buckets that are to be allocated for the table's hash index. Bucket count = (PAGES * 256) / 20. Therefore the number of buckets allocated for the hash index is 384: (30 * 256) / 20 = 384
CREATE TABLE Customer
(custId NUMBER NOT NULL PRIMARY KEY,
custName CHAR(100) NOT NULL,
Addr CHAR(100),
Zip NUMBER,
Region CHAR(10))
UNIQUE HASH ON (custId) PAGES = 30;
Estimating table size
ttSize to estimate database size.ttIsql tablesize command. For more information, see "Using the ttIsql tablesize command".
Implementing aging in your tables
ON or OFF). You can specify one of the following types of aging policies: usage-based or time-based. Usage-based aging removes least recently used (LRU) data within a specified database usage range. Time-based aging removes data based on the specified data lifetime and frequency of the aging process. You can define both usage-based aging and time-based aging in the same database, but you can define only one type of aging on a specific table.CREATE TABLE statement. You can add an aging policy to an existing table with the ALTER TABLE statement if the table does not already have an aging policy defined. You can change the aging policy by dropping aging and adding a new aging policy.
Usage-based aging
AGING LRU clause of the CREATE TABLE statement. Aging begins automatically if the aging state is ON.ttAgingLRUConfig built-in procedure to specify the LRU aging attributes. The attribute values apply to all tables in the database that have an LRU aging policy. If you do not call the ttAgingLRUConfig built-in procedure, then the default values for the attributes are used.
ttAgingLRUConfig built-in procedure requires that the user have ADMIN privilege if you want to modify any attributes. You do not need any privileges for viewing existing attributes. For more information, see "Built-In Procedures" in the Oracle TimesTen In-Memory Database Reference.
LRU Aging Attribute Description LowUsageThreshholdThe percent of the database PermSize at which LRU aging is deactivated.HighUsageThreshholdThe percent of the database PermSize at which LRU aging is activated.AgingCycleThe number of minutes between aging cycles. AgingCycle after an LRU aging policy has already been defined, aging occurs based on the current time and the new cycle time. For example, if the original aging cycle is 15 minutes and LRU aging occurred 10 minutes ago, aging is expected to occur again in 5 minutes. However, if you change the AgingCycle parameter to 30 minutes, then aging occurs 30 minutes from the time you call the ttAgingLRUConfig procedure with the new value for AgingCycle.SELECT statement.INSERT SELECT statement.ALTER TABLE statement to perform the following tasks:ALTER TABLE statement with the SET AGING {ON|OFF} clause.ALTER TABLE statement with the ADD AGING LRU [ON|OFF] clause.ALTER TABLE statement with the DROP AGING clause.ttAgingScheduleNow built-in procedure to schedule when aging starts. For more information, see "Scheduling when aging starts".ALTER TABLE statement with the DROP AGING clause. Then add time-based aging by using the ALTER TABLE statement with the ADD AGING USE clause.
Time-based aging
AGING USE clause of the CREATE TABLE statement. Add a time-based aging policy to an existing table with the ADD AGING USE clause of the ALTER TABLE statement.AGING USE clause has a ColumnName argument.ColumnName is the name of the column that is used for time-based aging. For brevity, we will call it the timestamp column. The timestamp column must be defined as follows:ORA_TIMESTAMP, TT_TIMESTAMP, TT_DATE data typeNOT NULL
NOT NULL.ORA_TIMESTAMP, TT_TIMESTAMP, or ORA_DATE, you can specify the lifetime in days, hours, or minutes in the LIFETIME clause of the CREATE TABLE statement. If the data type of the timestamp column is TT_DATE, specify the lifetime in days.SYSDATE. The result is truncated the result using the specified unit (minute, hour, day) and compared with the specified LIFETIME value. If the result is greater than the LIFETIME value, then the row is a candidate for aging.CYCLE clause to indicate how often the system should examine the rows to remove data that has exceeded the specified lifetime. If you do not specify CYCLE, aging occurs every five minutes. If you specify 0 for the cycle, then aging is continuous. Aging begins automatically if the state is ON.ALTER TABLE statement to perform the following tasks:SET AGING {ON|OFF} clause.SET AGING CYCLE clause.SET AGING LIFETIME clause.ADD AGING USE clause.DROP AGING clause.ttAgingScheduleNow built-in procedure to schedule when aging starts. For more information, see "Scheduling when aging starts"ALTER TABLE statement with the ADD AGING LRU clause.
Aging and foreign keys
ON DELETE CASCADE enabled, the setting is ignored.
Scheduling when aging starts
ttAgingScheduleNow built-in procedure to schedule the aging process. The aging process starts as soon as you call the procedure unless there is already an aging process in progress, in which case it will begin when that aging process has completed.ttAgingScheduleNow, the aging process starts regardless of whether the state is ON or OFF.ttAgingScheduleNow does not change the aging state. If the aging state is OFF when you call ttAgingScheduleNow, then the aging process starts, but it does not continue after the process is complete. To continue aging, you must call ttAgingScheduleNow again or change the aging state to ON.ON, then ttAgingScheduleNow resets the aging cycle based on the time ttAgingScheduleNow was called.ALTER TABLE statement with the SET AGING OFF clause. Then use ttAgingScheduleNow to start aging at the desired time.ttAgingScheduleNow to start or reset aging for an individual table by specifying its name when you call the procedure. If you do not specify a table name, then ttAgingScheduleNow will start or reset aging on all of the tables in the database that have aging defined.
Aging and replication
ACTIVE.
Understanding views
Creating a view
CREATE VIEW SQL statement. The syntax for all SQL statements is provided in the "SQL Statements" chapter in the Oracle TimesTen In-Memory Database SQL Reference.
CREATE VIEW ViewName AS SelectQuery;
t1:
CREATE VIEW v1 AS SELECT * FROM t1;
t1:
CREATE VIEW v1 (max1) AS SELECT max(x1) FROM t1;
The SELECT query in the CREATE VIEW statement
SELECT query used to define the contents of a materialized view is similar to the top-level SQL SELECT statement described in "SQL Statements" in the Oracle TimesTen In-Memory Database SQL Reference, with the following restrictions:SELECT * query in a view definition is expanded at view creation time. Any columns added after a view is created do not affect the view.SELECT statement that is creating a view:DISTINCTFIRSTORDER BYSELECT FOR UPDATE or SELECT FOR INSERT statements can be used on a view.
Dropping a view
DROP VIEW statement deletes the specified view.CustOrder view:
DROP VIEW CustOrder;
Restrictions on views and detail tables
FROM clause of a SELECT statement, 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 to form a legal 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.DROP TABLE statement. You must use the DROP VIEW statement.ALTER TABLE statement.
Understanding materialized views
Overview of materialized views
Synchronous materialized view
Asynchronous materialized view
FAST, which updates only the incremental changes since the last update.COMPLETE, which provides a full refresh.FAST refresh, you must create a materialized view log to manage the deferred incremental transactions for each detail table used by the asynchronous materialized view. Each detail table requires only one materialized view log for managing all deferred transactions, even if it is included in more than one FAST asynchronous materialized view.
When to use synchronous or asynchronous materialized views
Joins and aggregate functions turn into super locks
Freshness of the materialized view
Overhead cost
Working with materialized views
Creating a materialized view
CREATE MATERIALIZED VIEW.
CREATE TABLE customer(custId int not null,
custName char(100) not null,
Addr char(100),
Zip int,
Region char(10),
PRIMARY KEY (custId));
CREATE TABLE bookOrder(orderId int not null,
custId int not null,
book char(100),
PRIMARY KEY (orderId),
FOREIGN KEY (custId) REFERENCES Customer(custId));
Creating a synchronous materialized view
CREATE MATERIALIZED VIEW statement.SampleMV, that generates a result set from selected columns in the customer and bookOrder detail tables described above.
CREATE MATERIALIZED VIEW SampleMV AS
SELECT customer.custId, custName, orderId, book
FROM customer, bookOrder
WHERE customer.custId=bookOrder.custId;
Creating an asynchronous materialized view
REFRESH clause with at least one of the following:FAST or COMPLETE for the refresh method. FAST denotes an incremental refresh. COMPLETE indicates a full refresh. If the refresh method is omitted, then COMPLETE is the default refresh method. If you specify FAST, you must create the asynchronous materialized view log for each detail table associated with the materialized view.
FAST refresh.REFRESH MATERIALIZED VIEW statement, which is described at the end of this section.NEXT SYSDATE without specifying NUMTODSINTERVL(), the refresh is performed after every commit of any user transaction that updates the detail tables. This refresh is always performed in a separate transaction. The user transaction does not wait for the refresh to complete. The option to refresh at every commit is only supported for the fast refresh method.NEXT SYSDATE + NUMTODSINTERVAL(IntegerLiteral,IntervalUnit) clause. This option is supported for both FAST and COMPLETE refresh methods.IntegerLiteral must be an integer. IntervalUnit must be one of the following values: 'DAY', 'HOUR', 'MINUTE', or 'SECOND'.FAST refresh method, the deferred transactions are saved in a materialized view log. Thus, before you create an asynchronous materialized view, you must create a materialized view log for each detail table included in the asynchronous materialized view that uses FAST refresh. Each detail table can have only one materialized view log even if they are used by more than one asynchronous materialized view with FAST refresh. All columns referenced in an asynchronous materialized view must be included in the corresponding asynchronous materialized view log. If there is more than one asynchronous materialized view with FAST refresh created on a detail table, make sure to include all columns that are used in the different asynchronous materialized views created for that detail table in its asynchronous materialized view log.FAST refresh, where the deferred transactions are updated every hour after creation. First, create the materialized view log for each detail table, customer and bookOrder. The following statements create the materialized log views for customer and bookOrder to track the deferred transactions for the FAST refresh. The materialized view log for customer tracks the primary key and the customer name as follows:
CREATE MATERIALIZED VIEW LOG ON customer WITH PRIMARY KEY (custName);
CREATE MATERIALIZED VIEW LOG syntax, the primary key is included if you specify WITH PRIMARY KEY or do not mention either PRIMARY KEY or ROWID. All non-primary key columns that you want included in the materialized view log must be specified in the parenthetical column list.bookorder table tracks the primary key of orderId and columns custId, and book.
CREATE MATERIALIZED VIEW LOG ON bookOrder WITH (custId, book);
customer and bookOrder detail tables, you can create an asynchronous materialized view. The asynchronous materialized view must include either the ROWID or primary key columns for all the detail tables.SampleAMV that generates a result set from selected columns in the customer and bookOrder detail tables. The statement specifies a FAST refresh to update the deferred transactions every hour from the moment of creation.
CREATE MATERIALIZED VIEW SampleAMV
REFRESH
FAST
NEXT SYSDATE + NUMTODSINTERVAL(1, 'HOUR')
AS SELECT customer.custId, custName, orderId, book
FROM customer, bookOrder
WHERE customer.custId=bookOrder.custId;
REFRESH MATERIALIZED VIEW statement. You can manually refresh the materialized view at any time, even if a REFRESH interval is specified. For example, if there were multiple updates to the detail tables, you can manually refresh the SampleAMV materialized view as follows:
REFRESH MATERIALIZED VIEW SampleAMV;
The SELECT query in the CREATE MATERIALIZED VIEW statement
SELECT query used to define the contents of a materialized view is similar to the top-level SQL SELECT statement described in "SQL Statements" in the Oracle TimesTen In-Memory Database SQL Reference with some restrictions, which are described in "CREATE MATERIALIZED VIEW" in the Oracle TimesTen In-Memory Database SQL Reference.
Dropping a materialized view or a materialized view log
DROP VIEW statement.sampleMV materialized view.
DROP VIEW sampleMV;
sampleAMV, then the following statements drop the associated materialized view logs.
DROP MATERIALIZED VIEW LOG ON customer;
DROP MATERIALIZED VIEW LOG ON bookOrder;
Identifying the table associated with a materialized view log
MVLOG$_detailTableId, where detailTableId is the table id of the table on which it was created. The table id and table name are both recorded in SYS.TABLES. For example, if the materialized view log filename is MVLOG$_507244, then you can retrieve the table name from SYS.TABLES where the table id is 507244 as follows:
select tblname from sys.tables where tblid = 507244;
< T1 >
1 row found.
Restrictions on materialized views and detail tables
INSERT, DELETE, or UPDATE statement by replication, XLA, or the cache agent.
805: Update view table directly has not been implemented
DROP VIEW statement.DROP VIEW statement and then create a new materialized view with a CREATE MATERIALIZED VIEW statement.
Performance implications of materialized views
Managing performance for asynchronous materialized views
SELECT statement used in the CREATE MATERIALIZED VIEW statement. After every refresh, the processed rows in the materialized view log are deleted.ttOptUpdateStats and ttOptEstimateStats.
Managing performance for synchronous materialized views
UPDATE and INSERT operations may be impacted if the updated table is referenced in a materialized view. The performance impact depends on many factors, such as the following:V that selects from tables T1, T2, and T3, then any time you insert into T1, or update T2, or delete from T3, TimesTen performs "view maintenance."T1 will have a first stage of the plan where it updates the view V, followed by a second stage where it updates T1.WHERE clauses for the update or delete statements that frequently occur on the detail tables. Note any clause that uses an index key. For example, if the operations that an application performs 95 percent of the time are as follows:
UPDATE T1 set A=A+1 WHERE K1=? AND K2=?
DELETE FROMT2 WHERE K3=?
K1, K2) and K3.K1, K2, and K3.V.K1, V.K2) and one on V.K3. The indexes do not have to be unique. The names of the view columns can be different from the names of the table columns, though they are the same in this example.WHERE clause is used to do the corresponding update of the view. This allows maintenance to be executed in a batch, which has better performance.FROM clause (each detail table), check which ones are frequently changed by UPDATE, INSERT and CREATE VIEW statements. For example, a view's FROM clause may have tables T1, T2, T3, T4, and T5, but of those, only T2 and T3 are frequently changed.T2.rowid and T3.rowid.T2rowid and T3rowid, and indexes would be created on V.T2rowid and V.T3rowid.
Understanding indexes
Overview of index types
UNIQUE HASH option, which is specified over the columns that make up the primary key of a table.FIELD > 10, then the primary key index will not expedite finding the answer, but a separate index will.
AND and OR operators.
Creating an index
CREATE INDEX. TimesTen converts index names to upper case characters.SYS or with the user name TTREP if created during replication.
IxID over column CustID of table NameID.
CREATE INDEX IxID ON NameID (CustID);
UNIQUE HASH ON clause in the CREATE TABLE. However, TimesTen may create temporary hash and range indexes automatically during query processing to speed up query execution.
Altering an index
USE HASH INDEX of the ALTER TABLE statement.
Dropping an index
SYS.DROP INDEX SQL statement. All indexes in a table are dropped automatically when the table is dropped.
Estimating index size
ttSize to estimate database size.
Using the Index Advisor to recommend indexes
ORDER BY or GROUP BY operations. Then Index Advisor does not differentiate tables that are used for specific intentions, such as the base table for a materialized view or as a table within a cache group. As long as the table is used in queries in the SQL workload, the Index Advisor may recommend indexes on that table.CREATE statement for each recommended index, which you can choose to execute. A DBA should review each CREATE statement recommended for new indexes before they are applied since the Index Advisor may recommend the following:CREATE statement for the recommended index in the SQL workload after the DDL that creates the tables or columns of tables and before they are dropped.
Prepare for executing the Index Advisor
ttOptSetFlag built-in procedure that you would use for the SQL workload before enabling the Index Advisor and running the workload. For more details, see "ttOptSetFlag" in the Oracle TimesTen In-Memory Database Reference.ttOptUpdateStats, ttOptEstimateStats, or ttOptSetTblStats. In the built-in procedures, set the invalidate parameter to 1 to invalidate all commands that reference the indicated tables and force these commands to be automatically prepared again when re-executed. This ensures that statistics are up to date.ttOptUpdateStats built-in procedure provides a full update of all statistics for the tables. However, it can be time consuming.ttOptEstimateStats evaluates statistics based upon a small percentage of rows in the indicated tables.ttOptSetTblStats sets the statistics to known values provided by you.
CALL ttOptEstimateStats ( '', 1, '10 PERCENT' );
Capture the data used for generating index recommendations
ttIndexAdviceCaptureStart and ttIndexAdviceCaptureEnd built-in procedures to capture the information needed by the Index Advisor to generate index recommendations, as follows:ttIndexAdviceCaptureStart built-in procedure to start the process to collect index information.ttIndexAdviceCaptureEnd built-in procedure to end the index information collection process.
ttIndexAdviceCaptureStart built-in procedure to initiate the data collection process, provide the following:captureLevel parameter, specify whether the index information is to be collected for the current connection or for the entire database. You can execute multiple connection-level captures concurrently for independent connections without conflict. A database-level capture can take place in parallel with a connection-level capture. Since there is no conflict between a database-level and a connection-level capture, any outstanding connection-level captures that are already in progress when a database-level capture is initiated will complete as intended. However, an error is returned if you initiate a second request for a database-level capture while the first is still active; an error is also returned if a second request for a connection-level capture from the same connection is initiated while the first connection-level capture is still active.ttIndexAdviceCaptureStart for a database-level capture, any outstanding connection-level captures that are already in progress will complete.captureMode parameter designates that you want the data collection performed on one of the following scenarios:ttIndexAdviceCaptureEnd built-in procedure, which ends either an active connection-level capture from the same connection or an active database-level capture. Completing a database-level capture requires the ADMIN privilege.ADMIN privileges connects and invokes the ttIndexAdviceCaptureEnd built-in procedure to end a database-level capture.
ttIndexAdviceCaptureDrop to free the temporary space after a capture. See "Evaluate results of new indexes" for more information on ttIndexAdviceCaptureDrop.
Call ttIndexAdviceCaptureStart(0,0);
Call ttIndexAdviceCaptureEnd(0)
Retrieve index recommendations and data collection information
ttIndexAdviceCaptureInfoGet built-in procedure to retrieve data collection overview information for the Index Advisor.ttIndexAdviceCaptureOutput built-in procedure to retrieve the recommended indexes.
Retrieve data collection information with ttIndexAdviceCaptureInfoGet
ttIndexAdviceCaptureInfoGet built-in procedure retrieves information about the data collected for the Index Advisor. There will be at most a single row returned for a connection-level capture and at most a single row for a database-level capture.
ADMIN privileges.ttIndexAdviceCaptureInfoGet built-in procedure captures data if:
Command> CALL ttIndexAdviceCaptureInfoGet();
< 0, 1, 0, 0, 363, 369, 2012-07-27 11:44:08.136833, 2012-07-27 12:07:35.410993 >
1 row found.
Retrieve index recommendations with ttIndexAdviceCaptureOutput
ttIndexAdviceCaptureOutput built-in procedure retrieves the list of index recommendations from the last recorded capture at the specified level (connection or database-level). The list contains the CREATE statement for each recommended index.ttIndexAdviceCaptureOutput with captureLevel set to 0 in the same connection that initiated the capture. For a database-level capture, execute ttIndexAdviceCaptureOutput with captureLevel set to 1 in a connection where the user has ADMIN privilege.stmtCount - The number of times the index would be useful to speed up the executed SQL workload.createStmt - The executable statement that can be used to create the recommended index. All database object names in these statements are fully qualified.CREATE statement for an index called PURCHASE_i1 on the HR.PURCHASE table, which would be useful 4 times for this SQL workload.
CALL ttIndexAdviceCaptureOutput();
< 4, create index PURCHASE_i1 on HR.PURCHASE(AMOUNT); >
1 row found.
Evaluate results of new indexes
CREATE statements for the new indexes that have been approved by the DBA, perform the following:ttOptStatsExport built-in procedure from which you can restore the table statistics to the current state. When you apply these statements, you re-create the same environment. This ensures a consistent query plan is created for future executions. You can use this if you need to re-create the same query plan when investigating a query plan issue.ttIndexAdviceCaptureDrop built-in procedure.ttOptStatsExport built-in procedure to return the set of statements required to restore the table statistics to the current state. If no table is specified, ttOptStatsExport returns the set of statements required to restore the table statistics for all user tables that the calling user has permission to access.
employees table:
Command> CALL ttOptStatsExport('HR.employees');
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'EMPLOYEE_ID', 0, (6, 0, 107, 107,
(20, 20, 1 ,100, 120, 101), (20, 20, 1 ,121, 141, 122), (20, 20, 1 ,142, 162,
143), (20, 20, 1 ,163, 183, 164), (20, 20, 1 ,184, 204, 185), (1, 1, 1 ,205, 206,
205))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'FIRST_NAME', 0, (1, 0, 89, 107,
(89, 107, 0, 'Adam', 'Winston', 'Adam'))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'LAST_NAME', 0, (1, 0, 97, 107, (97,
107, 0, 'Abel', 'Zlotkey', 'Abel'))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'EMAIL', 0, (6, 0, 107, 107, (20,
20, 1, 'ABANDA', 'DGREENE', 'ABULL'), (20, 20, 1, 'DLEE', 'JKING', 'DLORENTZ'),
(20, 20, 1, 'JLANDRY', 'LOZER', 'JLIVINGS'), (20, 20, 1, 'LPOPP', 'RMATOS',
'LSMITH'), (20, 20, 1, 'RPERKINS', 'WGIETZ', 'SANDE'), (1, 1, 1, 'WSMITH',
'WTAYLOR', 'WSMITH'))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'PHONE_NUMBER', 0, (1, 0, 103, 107,
(103, 107, 0, '011.44.1343.329268', '650.509.4876', '011.44.1343.329268'))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'HIRE_DATE', 0, (1, 0, 90, 107, (90,
107, 0 ,'1987-06-17 00:00:00', '2000-04-21 00:00:00', '1987-06-17 00:00:00'))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'JOB_ID', 0, (4, 0, 19, 107, (11,
16, 5, 'AC_ACCOUNT', 'PR_REP', 'FI_ACCOUNT'), (3, 11, 30, 'PU_CLERK', 'SA_REP',
'SA_REP'), (1, 20, 20, 'SH_CLERK', 'ST_CLERK', 'ST_CLERK'), (0, 0, 5, 'ST_MAN',
'ST_MAN', 'ST_MAN'))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'SALARY', 0, (1, 0, 57, 107, (57,
107, 0 ,2100, 24000, 2100))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'COMMISSION_PCT', 0, (1, 72, 7, 107,
(7, 35, 0 ,0.1, 0.4, 0.1))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'MANAGER_ID', 0, (1, 1, 18, 107,
(18, 106, 0 ,100, 205, 100))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'DEPARTMENT_ID', 0, (3, 1, 11, 107,
(4, 10, 45 ,10, 50, 50), (2, 6, 34 ,60, 80, 80), (2, 5, 6 ,90, 110, 100))); >
< call ttoptsettblstats('HR.EMPLOYEES', 107, 0); >
12 rows found.
ttIndexAdviceCaptureDrop built-in procedure drops the existing data collected for the specified captureLevel, which can either be a connection or database-level capture. You must execute this built-in procedure twice to drop both a connection-level and database-level capture. You may not invoke this built-in procedure while a capture at the same level is in progress.
Call ttIndexAdviceCaptureDrop(0);
Example using Index Advisor built-in procedures
Command> CALL ttOptUpdateStats();
Command> CALL ttIndexAdviceCaptureStart();
Command> SELECT employee_id, first_name, last_name FROM employees;
< 100, Steven, King >
< 101, Neena, Kochhar >
< 102, Lex, De Haan >
< 103, Alexander, Hunold >
< 104, Bruce, Ernst >
...
< 204, Hermann, Baer >
< 205, Shelley, Higgins >
< 206, William, Gietz >
107 rows found.
Command> SELECT MAX(salary) AS MAX_SALARY
FROM employees
WHERE employees.hire_date > '2000-01-01 00:00:00';
< 10500 >
1 row found.
Command> SELECT employee_id, job_id FROM job_history
> WHERE (employee_id, job_id) NOT IN (SELECT employee_id, job_id
> FROM employees);
< 101, AC_ACCOUNT >
< 101, AC_MGR >
< 102, IT_PROG >
< 114, ST_CLERK >
< 122, ST_CLERK >
< 176, SA_MAN >
< 200, AC_ACCOUNT >
< 201, MK_REP >
8 rows found.
Command> WITH dept_costs AS (
> SELECT department_name, SUM(salary) dept_total
> FROM employees e, departments d
> WHERE e.department_id = d.department_id
> GROUP BY department_name),
> avg_cost AS (
> SELECT SUM(dept_total)/COUNT(*) avg
> FROM dept_costs)
> SELECT * FROM dept_costs
> WHERE dept_total >
> (SELECT avg FROM avg_cost)
> ORDER BY department_name;
< Sales, 304500 >
< Shipping, 156400 >
2 rows found.
Command> call ttIndexAdviceCaptureEnd();
Command> call ttIndexAdviceCaptureInfoGet();
< 0, 1, 0, 0, 9, 6, 2012-07-27 11:44:08.136833, 2012-07-27 12:07:35.410993 >
1 row found.
Command> call ttIndexAdviceCaptureOutput();
< 1, create index EMPLOYEES_i1 on HR.EMPLOYEES(SALARY); >
< 1, create index EMPLOYEES_i2 on HR.EMPLOYEES(HIRE_DATE); >
2 rows found.
Command> CALL ttOptStatsExport('HR.employees');
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'EMPLOYEE_ID', 0, (6, 0, 107, 107,
(20, 20, 1 ,100, 120, 101), (20, 20, 1 ,121, 141, 122), (20, 20, 1 ,142, 162,
143), (20, 20, 1 ,163, 183, 164), (20, 20, 1 ,184, 204, 185), (1, 1, 1 ,205, 206,
205))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'FIRST_NAME', 0, (1, 0, 89, 107,
(89, 107, 0, 'Adam', 'Winston', 'Adam'))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'LAST_NAME', 0, (1, 0, 97, 107, (97,
107, 0, 'Abel', 'Zlotkey', 'Abel'))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'EMAIL', 0, (6, 0, 107, 107, (20,
20, 1, 'ABANDA', 'DGREENE', 'ABULL'), (20, 20, 1, 'DLEE', 'JKING', 'DLORENTZ'),
(20, 20, 1, 'JLANDRY', 'LOZER', 'JLIVINGS'), (20, 20, 1, 'LPOPP', 'RMATOS',
'LSMITH'), (20, 20, 1, 'RPERKINS', 'WGIETZ', 'SANDE'), (1, 1, 1, 'WSMITH',
'WTAYLOR', 'WSMITH'))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'PHONE_NUMBER', 0, (1, 0, 103, 107,
(103, 107, 0, '011.44.1343.329268', '650.509.4876', '011.44.1343.329268'))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'HIRE_DATE', 0, (1, 0, 90, 107, (90,
107, 0 ,'1987-06-17 00:00:00', '2000-04-21 00:00:00', '1987-06-17 00:00:00'))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'JOB_ID', 0, (4, 0, 19, 107, (11,
16, 5, 'AC_ACCOUNT', 'PR_REP', 'FI_ACCOUNT'), (3, 11, 30, 'PU_CLERK', 'SA_REP',
'SA_REP'), (1, 20, 20, 'SH_CLERK', 'ST_CLERK', 'ST_CLERK'), (0, 0, 5, 'ST_MAN',
'ST_MAN', 'ST_MAN'))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'SALARY', 0, (1, 0, 57, 107, (57,
107, 0 ,2100, 24000, 2100))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'COMMISSION_PCT', 0, (1, 72, 7, 107,
(7, 35, 0 ,0.1, 0.4, 0.1))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'MANAGER_ID', 0, (1, 1, 18, 107,
(18, 106, 0 ,100, 205, 100))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'DEPARTMENT_ID', 0, (3, 1, 11, 107,
(4, 10, 45 ,10, 50, 50), (2, 6, 34 ,60, 80, 80), (2, 5, 6 ,90, 110, 100))); >
< call ttoptsettblstats('HR.EMPLOYEES', 107, 0); >
12 rows found.
Command> call ttIndexAdviceCaptureDrop();
Understanding rows
hh:mm:ss [AM|am|PM|pm].yyyy-mm-dd.yyyy-mm-dd hh:mm:ss.
Inserting rows
INSERT or INSERT SELECT. You can also use the ttBulkCp utility.
NameID, enter:
INSERT INTO NameID VALUES(23125, 'John Smith';
Understanding synonyms
SYS.ALL_SYNONYMS: describes the synonyms accessible to the current user.SYS.DBA_SYNONYMS: describes all synonyms in the database.SYS.USER_SYNONYMS: describes the synonyms owned by the current user.
Creating synonyms
CREATE SYNONYM statement. You can use the CREATE OR REPLACE SYNONYM statement to change the definition of an existing synonym without needing to drop it first. The CREATE SYNONYM and CREATE OR REPLACE SYNONYM statements specify the synonym name and the schema name in which the synonym is created. If the schema is omitted, the synonym is created in the user's schema. However, when creating public synonyms, you do not provide the schema name as it will be defined in the PUBLIC namespace.CREATE SYNONYM or CREATE OR REPLACE SYNONYM statements, the user must have the appropriate privileges, as described in "Object privileges for synonyms".CREATE SYNONYM and CREATE OR REPLACE SYNONYM statements define an alias for a particular object, which can be one of the following object types: table, view, synonym, sequence, PL/SQL stored procedure, PL/SQL function, PL/SQL package, materialized view, or cache group.
synjobs for the jobs table. Execute a SELECT statement on both the jobs table and the synjobs synonym to show that selecting from synjobs is the same as selecting from the jobs table. Finally, to display the private synonym, the example executes a SELECT statement on the SYS.USER_SYNONYMS table.
Command> CREATE SYNONYM synjobs FOR jobs;
Synonym created.
Command> SELECT FIRST 2 * FROM jobs;
< AC_ACCOUNT, Public Accountant, 4200, 9000 >
< AC_MGR, Accounting Manager, 8200, 16000 >
2 rows found.
Command> SELECT FIRST 2 * FROM synjobs;
< AC_ACCOUNT, Public Accountant, 4200, 9000 >
< AC_MGR, Accounting Manager, 8200, 16000 >
2 rows found.
Command> SELECT * FROM sys.user_synonyms;
< SYNJOBS, TTUSER, JOBS, <NULL> >
1 row found.
Dropping synonyms
DROP SYNONYM statement to drop an existing synonym from the database. A user cannot be dropped unless all objects, including synonyms, owned by this user are dropped.pubemp:
DROP PUBLIC SYNONYM pubemp;
Synonym dropped.
Synonyms may cause invalidation or recompilation of SQL queries
PKZdR)T T PK \8–A OEBPS/content.opfp3Ì
2 Working with the TimesTen Client and Server
Overview of the TimesTen Client/Server
Description of "Figure 2-1 Diagram of TimesTen Client and TimesTen Server"
Restrictions on client/server communication
ttAdmin, ttRepAdmin, and ttBackup. The utilities that can be executed over a client/server connection on the UNIX platform are named with a suffix of CS, such as ttIsqlCS, ttBulkCpCS, ttMigrateCS and ttSchemaCS. These utilities have been linked with the TimesTen Client driver and can be used to connect to Client DSNs when accessing a database over a client/server connection. Each utility listed in the Oracle TimesTen In-Memory Database Reference provides the name of the client/server version of that utility, if there is one.ttCacheUidPwdSet built-in procedure cannot be used over a client/server connection.CREATE USER or ALTER USER statements using a direct connection to the TimesTen database. Once created, the user that connects from the client to the server must be granted the CREATE SESSION privilege or the connection will fail. For more information on how to create the user on the TimesTen database and how the administrator grants the CREATE SESSION privilege, see "Creating or identifying users to the database" and "Granting privileges to connect to the database".fork() to use a connection opened by the parent process returns an error.
Communication protocols for Client/Server communication
-serverPool option in the ttendaemon.options file on the server machine, you can pre-spawn a reserve pool of server processes. See "Prespawning TimesTen Server processes" for details.
TCP/IP Communication
Shared memory communication
ttendaemon.options file. See "Using shared memory for Client/Server IPC".ttShmHost in the logical server name. See "Defining a logical server name" for details.
UNIX domain socket communication
ttLocalHost. See "Defining a logical server name" for more information.
Configuring TimesTen Client and Server
Overview of TimesTen Client/Server configuration
Description of "Figure 2-2 Configuring for a client/server connection"
ODBC.INI file with the server host name, either the logical server name or the actual server machine name, and the Server DSN that identifies the TimesTen database on the server.ODBC.INI file with the TimesTen database name and its connection attributes. The connection attributes specify how the TimesTen database is loaded and configured, and how the connections to it are to be controlled or managed.
Installing and configuring for client/server connections
Configuring Client/Server of the same TimesTen release
Install and configure the TimesTen Server
Install and configure the TimesTen Client
CLASSPATH and the shared library search path. See "Setting the environment for Java development" in the Oracle TimesTen In-Memory Database Java Developer's Guide for details.tnsnames.ora or easy connect as described in "Connecting to a TimesTen database from OCI" in the Oracle TimesTen In-Memory Database C Developer's Guide.
Configuring cross-release TimesTen Client/Server
ttLocalHost, then the platforms for the client and the server must be UNIX. The bit level and the release level for the client and server hosts must be the same.ttShmHost, then the platforms for the client and server can be either Windows or UNIX. The bit level may be different on the client and server hosts.
Defining Server DSNs
ttendaemon.options). If you have set the same connection attributes in both the Server DSN and the daemon options file, the value of the connection attributes in the Server DSN takes precedence.
ODBC.INI file or the ODBC Data Source Administrator:
Server DSN connection attributes defined in ODBC.INI file
ttDaemonAdmin -restartserver
MaxConnsPerServer: Set the maximum number of client connections that are handled by a single server process. The server is referenced by the Server DSN. The server may have multiple server processes, where each process can only have the maximum number of connections as specified by this attribute.ServersPerDSN: You can have multiple server processes serving multiple incoming connections on the server. The ServersPerDSN attribute specifies the number of server processes that are initially spawned on the server. Each new incoming connection spawns a new server process up to the ServersPerDSN. When ServersPerDSN is reached, the existing server processes handle multiple connections up to the number specified in MaxConnsPerServer.ServerStackSize: Set the size of the stack on the Server for each connection.MaxConnsPerServer and ServersPerDSN attributes are related. Neither of these attributes limits the number of client connections to given DSN. Instead, they control how connections are distributed over server processes. For example, if MaxConnsPerServer is set to 2 and ServersPerDSN is set to 5, then the following occurs:ServersPerDSN is reached, and MaxConnsPerServer is not, connection 6 is given to the first server process. Incoming connections 7 through 10 are given respectively as the second connection to server processes 2 through 5.ServersPerDSN and MaxConnsPerServer are reached, so server process 6 is started to handle connection 11.
Server DSN connection attributes defined in ODBC Data Source Administrator
Description of "Figure 2-3 Server tab in TimesTen ODBC Administrator"
Defining a logical server name
Creating and configuring a logical server name on Windows
Type of connection Network Address Local client/server connection that uses shared memory for inter-process communication ttShmHostRemote client/server connection The name of the machine where the TimesTen Server is running. For example, server. mycompany.com
Description of the illustration server.gif
Creating and configuring a logical server name on UNIX
SYSTTCONNECTINI environment variable. This file is referred to as the TTCONNECT.INI file. The file contains a description, a network address and a port number.
Type of connection Network address Local client/server connection that uses UNIX domain sockets ttLocalHostLocal client/server connection that uses shared memory for inter-process communication ttShmHostRemote client/server connection The name of the machine where the TimesTen Server is running. For example, server. mycompany.comSYSTTCONNECTINI environment variable, if it is setdaemon_home_dir/sys.ttconnect.ini file
TTCONNECT.INI file defines a logical server name, ttserver_logical, for a TimesTen Server running on the machine server.mycompany.com and listening on port 53385. The instance name of the TimesTen installation is tt1122.
[ttserver_logical]
Description=TimesTen Server 11.2.2
Network_Address=server.mycompany.com
TCP_Port=53385
TTCONNECT.INI file might look like:
[LocalHost_tt1122_32]
Description=Local TimesTen Server TimesTen release 11.2.2 through domain sockets
Network_Address=ttLocalHost
TCP_PORT=53385
TTCONNECT.INI file might look like:
[ShmHost_tt1122]
Description= Local TimesTen Server TimesTen release 11.2.2 through shared memory
Network_Address=ttShmHost
TCP_PORT=53385
Working with the TTCONNECT.INI file
TTCONNECT.INI file to define the names and attributes for servers and the mappings between logical server names and their network addresses. This information is stored on machine where the TimesTen Client is installed. By default, the TTCONNECT.INI file is install_dir/sys.ttconnect.ini.SYSTTCONNECTINI environment variable to the name and location of the TTCONNECT.INI file before launching the TimesTen application.
Defining a server name on UNIX
TTCONNECT.INI file. The format of a TimesTen Server specification in the TTCONNECT.INI file is shown in Table 2-1.
Component Description
ServerName]
Description=description
Network_Address=network-address
TCP_Port=port-number
[ttserver]
Description=TimesTen Client/Server
Network_Address=server.company.com
TCP_Port=53385
ttLocalHost. The server specification might appear as:
[LocalHost1122]
Description=Shm TimesTen Client/Server
Network_Address=ttLocalHost
TCP_Port=53385
ttShmHost. The server specification might appear as:
[ShmHost1122]
Description=Shm TimesTen Client/Server
Network_Address=ttShmHost
TCP_Port=53385
Creating Client DSNs
hostname, DSN pair, where the hostname represents the server machine on which TimesTen Server is running and the DSN refers to a Server DSN that is defined on that host. These are configured within the Client DSN connection attributes.
connection string that is passed to the ODBC SQLDriverConnect function or the URL string that is passed to the JDBC DriverManager.getConnection() method. For example, you could use the TTC_SERVER_DSN attribute in either the connection string or the Client DSN for a client to specify which DSN it should use on the server.
Creating and configuring Client DSNs on Windows
Creating a Client DSN on Windows
Description of the illustration add_dsn.gif
Description of the illustration setup_adv.gif
Boston_Accounts and Chicago_Accounts where Boston and Chicago are logical server names and Accounts is a Server DSN.TCP_Port attribute.US7ASCII. For more information, see "ConnectionCharacterSet" in Oracle TimesTen In-Memory Database Reference.
Setting the timeout interval and authentication
UID, PWD, and Timeout attributes. However, configuring the authentication in the Client DSN is optional, since you can provide the user name and password when connecting. If you do supply the user name and password in the Client DSN, the password is stored unencrypted on the client.UID, PWD, and Timeout attributes, see "Connection Attributes" in the Oracle TimesTen In-Memory Database Reference.
Accessing a remote database on Windows
client.mycompany.com. The client application is accessing the Server DSN on the remote server machine, server.mycompany.com. The logical server name is ttserver_logical.
_32. On 64-bit platforms, the sample DSNs are appended with _64.server.mycompany.com, use the ttStatus utility to verify that the TimesTen Server is running and to verify the port number it is listening on.RunData1122_32, is defined as a System DSN on server.mycompany.com.client.mycompany.com, create a Logical Server Name entry for the remote TimesTen Server. In the TimesTen Logical Server Name Setup dialog:ttserver_logical.server.mycompany.com.53385. This is the default port number for the TimesTen Server on 32-bit platforms for TimesTen Release 11.2.2. This value should correspond to the value displayed by ttStatus in Step 1.client.mycompany.com, create a Client DSN that corresponds to the remote Server DSN, RunData_tt1122_32. In the TimesTen Client DSN Setup dialog, enter the following values:RunDataCS_tt1122_32.ttserver_logical.RunData1122_32.client.mycompany.com using the Client DSN, RunDataCS_tt1122. The example below uses the ttIsqlCS program installed with TimesTen Client.
ttIsqlCS connStr "DSN=RunDataCS_tt1122_32"
server.mycompany.com and the Server is listening on Port 53385. The following methods can be used to connect to a Server DS:logical_server with server.mycompany.com as the Network Address and 53385 as the Network Port. Define a Client DSN with logical_server as the Server name, Server_DSN as the Server DSN. And execute the command:
ttIsqlCS -connStr "DSN=Client_DSN"
logical_server with server.mycompany.com as the Network Address and the default port number as the Network Port. Define a Client DSN with logical_server as the Server name, Server_DSN as the Server DSN. Overwrite the port number in the command:
ttIsqlCS -connStr "DSN=Client_DSN; TCP_Port=53385"
ttIsqlCS -connStr "TTC_Server=server.mycompany.com;
TTC_Server_DSN=Server_DSN; TCP_Port=53385"
Testing connections
Description of the illustration setup_adv.gif
Creating and configuring Client DSNs on UNIX
TTCONNECT.INI file; you define Client DSNs by editing the user ODBC.INI file for user DSN or the system ODBC.INI file for system DSNs. For a description of user and system DSNs, see "Specifying Data Source Names to identify TimesTen databases".
ODBC.INI file is described in "ODBC.INI file entry descriptions".ODBC.INI file, add an entry for the Client DSN. The Client DSN specifies the location of the TimesTen database with the following attributes:TTC_Server attribute.TTC_Server_DSN attribute.
[ODBC Data Sources]
Client_DSN=name-of-ODBC-driver
RunDataCS_tt1122_32 as the Client DSN and associate it with the TimesTen Client ODBC driver, you would make the following entry in the ODBC Data Sources section of the ODBC.INI file:
[ODBC Data Sources]
RunDataCS_tt1122_32=TimesTen Client 11.2.2
ODBC.INI file requires a its own specification section.RunData_tt1122_32 where the server is configured with a logical server name of ttserver_logical and the Server DSN is RunData_tt1122_32:
[RunDataCS_tt1122_32]
TTC_Server=ttserver_logical
TTC_Server_DSN=RunData_tt1122_32
TTC_SERVER* attributes are the main attributes for a Client DSN definition. There are only a few client attributes, each of which are for identifying the server. If you provide any server attributes in the client definition, these attributes are ignored. For a description of all the Client DSN attributes used in the ODBC.INI file, see "Connection Attributes" in the Oracle TimesTen In-Memory Database Reference.
Using automatic client failover
Features and functionality of automatic client failover
TTC_Timeout connection attribute. The minimum timeout is 60 seconds, regardless of the TTC_Timeout setting. Refer to "TTC_Timeout" in Oracle TimesTen In-Memory Database Reference for information about that attribute.
Connections attribute (upper limit of the number of concurrent connections to the database). The number of server processes, in turn, is affected by the setting of the MaxConnsPerServer attribute (maximum number of concurrent connections a child server process can handle). For example, if you have 12 connections and MaxConnsPerServer=3, then there will be four server processes. Therefore, if some of the connections use automatic client failover, there will be four additional connections.
Configuring automatic client failover
Configuring automatic client failover on Windows
TCP_Port attribute.
Configuring automatic client failover on UNIX
ODBC.INI file on the client, define the client DSNs for the standby node by configuring TTC_SERVER2 to the server on which the standby database resides. Set TTC_SERVER_DSN2 to the name of the standby database.
[MYDSN FAILOVER]
TTC_SERVER=localhost
TTC_SERVER_DSN=MYDSN
TTC_Timeout=60
ConnectionCharacterSet=AL32UTF8
TTC_SERVER2=localhost
TTC_SERVER_DSN2=MYDSNSTANDBY
sys.ttconnect.ini, which are equivalent to TTC_Server, TTC_Server_DSN, and TCP_Port, but configure the standby node.
TTC_Server2
TTC_Server_DSN2
TCP_Port2
TTC_Server2, TTC_Server_DSN2, or TCP_Port2 implies the following:TTC_FAILOVERPORTRANGE connection attribute to specify a port or port range where the failover thread listens for failover notifications. By default, a port chosen by the operating system will be used. To accommodate firewalls between the client and server systems, you must specify one value for a UDP port number or a range of UDP port numbers. A port range is set as a lower and upper value separated by hyphen.
TTC_Server2, TTC_Server_DSN2, and TCP_Port2 can be specified in the connection string, overriding any settings in the DSN.TTC_Server2 is specified but TTC_Server_DSN2 and TCP_Port2 are not, then TTC_Server_DSN2 is set to the TTC_Server_DSN value and TCP_Port2 is set to the TCP_Port value.TTC_Server_DSN, it will try the standby, TTC_Server_DSN2.TTC_Server and TTC_Server2 can have the same setting if it is a virtual IP address.
Running the TimesTen Server
ttDaemonAdmin utility.SYSTEM. On UNIX, the TimesTen Server is run as the instance administrator.
Accessing a remote database on UNIX
client.mycompany.com. The client application is accessing the Server DSN RunData_tt1122_32 on the remote server machine, another 32-bit Solaris machine, server.mycompany.com. The logical server name is ttserver_logical. The instance name of the TimesTen installation is tt1122_32.server.mycompany.com, use the ttStatus utility to verify that the TimesTen Server is running and to verify the port number on which it is listening.RunData_tt1122_32 exists in the system ODBC.INI file on server.mycompany.com.ODBC.INI file as follows:
[RunData_tt1122_32]
Driver=install_dir/lib/libtten.so
DataStore=install_dir/server/RunData_tt1122_32
TTCONNECT.INI file on client.mycompany.com.
[ttserver_logical]
# This value for TCP_Port should correspond to the
# value reported by ttStatus when verifying that the
# server is running
Network_Address=server.mycompany.com
TCP_Port=53385
TTCONNECT.INI file.client.mycompany.com, create a Client DSN corresponding to the remote Server DSN, RunData_tt1122_32.ODBC.INI file as follows:
[RunDataCS_tt1122_32]
TTC_SERVER=ttserver_logical
TTC_SERVER_DSN=RunData_tt1122_32
ODBC.INI file.client.mycompany.com using the Client DSN, RunDataCS_tt1122_32. The example below uses the ttIsql program that is installed with TimesTen Client.
ttIsqlCS -connStr "DSN=RunDataCS_tt1122_32"
server.mycompany.com and the Server is listening on Port 53385. The following methods can be used to connect to a Server DS:logical_server with server.mycompany.com as the Network Address and 53385 as the Network Port. Define a Client DSN with logical_server as the server name, Server_DSN as the Server DSN. Execute the command:
ttIsqlCS -connStr "DSN=Client_DSN"
logical_server with server.mycompany.com as the Network Address and the default port number as the Network Port. Define a Client DSN with logical_server as the server name, Server_DSN as the Server DSN. Overwrite the port number in the command:
ttIsqlCS -connStr "DSN=Client_DSN; TCP_Port=53385"
ttIsqlCS -connStr "TTC_Server=server.mycompany.com;
TTC_Server_DSN=Server_DSN; TCP_Port=53385"
Testing connections
ping from the client machine to see if a response is received from the server machine.telnet to connect to the port on which the TimesTen Server is listening. For example:
telnet server.mycompany.com 53385
Connected to server.mycompany.com
telnet: Unable to connect to remote host: Connection refused
ttStatus utility on the server machine to determine the status and port number of the TimesTen Server. Generally, the TimesTen Server is started at installation time. If the TimesTen Server is not running, you must start it. For information on starting the TimesTen Server, see "Modifying the TimesTen Server options".TTCONNECT.INI file contains the correct information.TTCONNECT.INI file is correct, check that a Server DSN corresponding to the database has been defined properly in the system ODBC.INI file on the machine where the database resides and where the TimesTen Server is running.
