< previous page page_403 next page > Page 403 If the feature had been turned off in the above example, the percent sign would have been placed in the buffer as part of the SELECT statement. SUFFIX The SUFFIX setting controls the default extension used for command files: SET SUF[FIX] extension where: SET SUF[FIX] Is the command, which may be abbreviated to SET SUF. extension Is the default extension to use when referring to SQL files. The default value for this setting is SQL. This setting is used by commands such as START, @, SAVE, and others that refer to SQL files. It does not apply to files created with the SPOOL command. Operational Settings Operational settings control various aspects of how your commands are executed and how SQL*Plus interacts with the database. You can control the following items: APPINFO Controls automatic registration of command files using the DBMS_ APPLICATION_INFO package. ARRAYSIZE Is the number of rows SQL*Plus will return at once from the database. AUTOCOMMIT Controls whether or not SQL*Plus automatically commits your changes. CLOSECURSOR Controls whether or not SQL*Plus keeps the statement cursor open all the time. COMPATIBILITY Controls whether SQL*Plus acts as if it is connected to a version 7 database or a version 8 database. COPYCOMMIT Controls how often SQL*Plus commits during the execution of a COPY command. < previous page page_403 next page > < previous page page_404 next page > Page 404 FLAGGER Controls whether or not SQL*Plus checks your statements for compliance with ANSI/ISO syntax. FLUSH Controls whether or not output may be buffered. The following sections describe the operational settings in detail. SET APPINFO The APPINFO setting controls whether or not SQL*Plus automatically registers command files using the DBMS_APPLICATION_INFO package: SET APPI[NFO] {OFF¦ON app_text} where: SET APPI[NFO] Is the command, which may be abbreviated to SET APP. OFF Disables the automatic registration of command file names. With this off, SQL*Plus will make an entry using the current value of app_text whenever you execute a command file. ON Enables the automatic registration of command files. This is the default setting. app_text Provides a text string that is used instead of the command file name. The default setting for this is SQL*Plus. The DBMS_APPLICATION_INFO package is defined in the Oracle Tuning manual. Among other things, this package controls the contents of the module field in both the V$SESSION and V$SQLAREA views. Whenever you connect to a database, SQL*Plus registers itself as the active application by making a call to the DBMS_APPLICATION_INFO.SET_MODULE procedure. This sets the module name for your session to SQL*Plus. This is reflected in. the v$session view, as the following example demonstrates: SQL> SELECT module FROM v$session WHERE username=USER; MODULE SQL*Plus SQL*Plus has the ability to update the module name whenever you execute a command file. The module name can be set to either the command file name or to some arbitrary text that you specify. The default setting for APPINFO causes < previous page page_404 next page > < previous page page_405 next page > Page 405 SQL*Plus to register the name of each command file you execute. So, if you execute a command file from one SQL*Plus session and query the v$session view from a second SQL*Plus session, you will get results like the following: SQL> SELECT module FROM v$session WHERE username= JEFF; MODULE 01@ c:\a\project_hours_dollars.SQL The module column now tells you the name of the command file being executed by the user named JEFF. SQL*Plus actually crams in a bit more information than just the filename. You can break down the format of the module field as follows: NL@tFFFFFFFF where: NL Is the nesting level. Command files executed from the SQL*Plus prompt will have a 01 in this position. If one command file executes another command file, then the nesting level will be 02, indicating that a second command file was invoked. The deeper the command files are nested, the larger this number becomes. @ Is a constant. t Is a flag indicating whether or not SQL*Plus had to truncate the name of the command file in order for it to fit within the module field. The maximum length of a module is 48 bytes. If the filename was truncated, this value will be a less- than sign (<). FFFFFFFF Is the filename, or as much as will fit within 48 characters. You may find that you don't care about command file names, but that you just want to know when users are using SQL*Plus. You can accomplish that by setting APPINFO to OFF. In that case, SQL*Plus will still register itself, but will not subsequently change the module name. It will always be SQL*Plus. For this to apply to all users, you would need to place the setting in each user's global or site profile. An additional option is to supply a fixed text string that SQL*Plus can use instead of a filename. This string is passed as the module name whenever a command file is executed. The result is that while you will know that a command file is being executed, you won't know which one. SET ARRAYSIZE The ARRAYSIZE setting controls the number of rows SQL*Plus fetches from the database at one time. < previous page page_405 next page > < previous page page_406 next page > Page 406 SET ARRAY[SIZE] array_size where: SET ARRAY[SIZE] Is the command, which may be abbreviated to SET ARRAY. array_size Is the number of rows fetched at one time. The default value is 15. The allowed range is from 1 to 5000. Increasing the arraysize allows SQL*Plus to return more rows in one fetch, thus lessening the required number of network round trips between it and the database server. The tradeoff is that larger arraysize settings require more memory. Using the default value of 15, SQL*Plus would require 10 fetches to return 150 rows from a query. By increasing the arraysize to 50, you reduce the number of fetches to three. SET AUTOCOMMIT The autocommit setting controls whether or not SQL*Plus automatically commits changes you make to the database. It also controls how often those changes are committed. SET AUTO [COMMIT] {OFF¦ ON¦ IMMEDIATE¦ statement_count} where: SET AUTO[COMMIT] Is the command, which may be abbreviated to SET AUTO. OFF Turns autocommit off, and requires you to commit (or rollback) changes manually. This is the default setting. ON Causes SQL*Plus to issue a COMMIT after each successful SQL statement or PL/SQL block you execute. IMMEDIATE Has the same effect as ON. statement_count Causes SQL*Plus to issue a COMMIT after successfully executing the specified number of SQL queries or PL/SQL blocks. This value may range from 1 to 2,000,000. When you set autocommit to occur after a specified number of successful SQL statements, be aware that manually executing a COMMIT, a ROLLBACK, or < previous page page_406 next page > < previous page page_407 next page > Page 407 another SET AUTOCOMMIT command will cause the counter to be reset back to zero. Take a look at the following example: SET AUTOCOMMIT 5 DELETE FROM project_hours WHERE employee_id = 101 AND project_id = 1001; DELETE FROM project_hours WHERE employee_id = 102 AND project_id = 1001; COMMIT; DELETE FROM project_hours WHERE employee_id = 103 AND project_id = 1001; DELETE FROM project_hours WHERE employee_id = 104 AND project_id = 1001; DELETE FROM project_hours WHERE employee_id = 105 AND project_id = 1001; DELETE FROM project_hours WHERE employee_id = 106 AND project_id = 1001; DELETE FROM project_hours WHERE employee_id = 107 AND project_id = 1001; The COMMIT statement in the fourth line will cause the counter to be reset. Counting will start over again, and five more SQL statements must be executed successfully before an automatic commit occurs. SET CLOSECURSOR The CLOSECURSOR setting controls whether or not SQL*Plus closes the cursor used to execute an SQL statement after the statement has executed: SET CLOSECUR[SOR] {OFF ¦ ON} where: SET CLOSECUR[SOR] Is the command, which may be abbreviated to SET CLOSECUR. OFF Causes SQL*Plus to leave the cursor open for use by subsequent SQL statements. This is the default setting. ON Causes SQL*Plus to close the cursor after a SQL statement has been executed. While you normally think of a cursor only in the context of returning data from a SELECT statement, Oracle also uses cursors to execute other SQL statements, such as DELETE, INSERT, UPDATE, and so forth. The same cursor can be used to execute many SQL statements, so SQL*Plus leaves it open all the time by default. SET COMPATIBILITY Use SET COMPATIBILITY to tell SQL*Plus the version of Oracle to which you are connected: SET COM[PATIBILITY] {V7 ¦V8 ¦ NATIVE} where: SET COM[PATIBILITY] Is the command, which may be abbreviated to SET COM. < previous page page_407 next page > < previous page page_408 next page > Page 408 V7 Tells SQL*Plus you are connected to a version 7 server, or that you want SQL*Plus to act as if you were. V8 Tells SQL*Plus you are connected to a version 8 database. NATIVE Causes SQL*Plus to automatically determine the compatibility setting based on the version of the database to which you are connected. This is the default setting. This setting controls the way SQL statements are transmitted to the server and the way the results are brought back. It's usually best just to leave this at the default setting, which causes SQL*Plus to automatically choose the correct method based on the database to which you are connected. SET COPYCOMMIT The copycommit setting controls how often SQL*Plus commits during execution of a COPY command: SET COPYC[OMMIT] batch_count where: SET COPYC[OMMIT] Is the command, which may be abbreviated to SET COPYC. batch_count Is the maximum number of uncommitted batches you want to allow during a copy operation. After this many batches are sent to the server, SQL*Plus commits the changes and resets the counter before sending another. The default value is 0, which means that SQL*Plus commits changes only when the COPY command is finished. The maximum value for this setting is 5000. Normally, when you execute a COPY command, SQL*Plus copies all the rows from the source table to the destination table, then commits those changes. This can make for a rather large transaction if you are copying a large number of records, and your rollback segments may not be big enough to accommodate it. You can use SET COPYCOMMIT to have SQL*Plus periodically commit the changes, thus reducing the transaction size. The copycommit setting works in conjunction with the arraysize setting. The arraysize setting controls the number of rows in a batch. The copycommit setting controls how many batches are copied before committing. The number of rows copied before each commit is equal to ARRAYSIZE * COPYCOMMIT. Take a look at this example: SET ARRAYSIZE 15 SET COPYCOMMIT 10 < previous page page_408 next page > < previous page page_409 next page > Page 409 COPY TO jonathan/chatham@jonathan CREATE employee_copy USING SELECT * FROM employee; Because the arraysize is 15 and the copycommit setting is 10, the COPY statement shown here will commit changes after every 150 rows (15 * 10). SET FLAGGER Use SET FLAGGER to have your SQL statements checked for conformance to ANSI/ISO SQL92 syntax. There are three compliance levels to choose from: entry, intermediate, and full. SET FLAGGER {OFF¦ENTRY¦INTERMED[IATE] ¦FULL} where: SET FLAGGER Is the command, which may not be abbreviated. OFF Turns this feature off. This is the default setting. ENTRY Allows SQL statements that use only the entry-level features of the standard. INTERMED[IATE] Allows SQL statements that use the intermediate-level features of the standard. FULL Allows any SQL statement that is defined in the standard. Using the SET FLAGGER command has the same effect as executing the ALTER DATABASE SET FLAGGER command. However, SET FLAGGER is a SQL*Plus command, so you can execute it even before connecting to the database. Once you've turned this feature on, any attempt to execute a nonconforming command will result in an error message like the following: ERROR: ORA-00097: Use of Oracle SQL feature not in SQL92 Entry Level This feature is useful if you are writing software for the federal government and are required to deliver an implementation that uses no non-standard, vendor-specific features. SET FLUSH The flush setting indicates whether or not the host operating system is allowed to buffer output: SET FLU[SH] {OFF¦ON} < previous page page_409 next page > < previous page page_410 next page > Page 410 where: SET FLU[SH] Is the command, which may be abbreviated to SET FLU. OFF Allows output to be buffered. ON Causes output to be displayed immediately. If you are running a command file, turning flush off might keep you from seeing any output until SQL*Plus is finished executing that file. Substitution Variable Settings Substitution variable settings allow you to change the way SQL*Plus handles substitution variables. The following settings make up this category: CONCAT Specifies the concatenation character, which marks the end of a substitution variable. DEFINE Specifies the character used to mark a substitution variable. ESCAPE Specifies the escape character. SCAN Controls whether or not the substitution feature is enabled. Most of these settings are described, with examples, in Chapter 4, Writing SQL*Plus Scripts. They are described here as well, in the following sections. SET CONCAT The SET CONCAT command allows you to change the character used to terminate a substitution variable reference. You can also use the command to turn the feature off so that SQL*Plus doesn't recognize any character as the terminator. SET CON[CAT] {OFF¦ON¦concat_char} where: SET CON[CAT] Is the command, which may be abbreviated to SETCON. OFF Turns this feature off completely. SQL*Plus won't recognize any character as the termination character for substitution variable names. < previous page page_410 next page > < previous page page_411 next page > Page 411 ON Turns this feature back on, and resets the character back to the default value of a period. concat_char Is the new termination character. The default value is a period. This setting is important only when you immediately follow a substitution variable name with characters that SQL*Plus might interpret as part of the name. Consider the following example: DEFINE table=PROJECT SELECT &&table._name FROM &&table; The period (or concatenation character) in the SELECT statement is used to terminate the reference to &&table. Without the period, SQL*Plus would recognize &&table_name as the substitution variable. The concatenation character is never left in the line. When SQL*Plus substitutes a value for the variable, the concatenation character goes away along with the variable name. SET DEFINE The SET DEFINE command allows you to change the prefix character used to mark substitution variables. You can also use SET DEFINE to turn variable substitution off. SET DEF[INE] {OFF¦ON¦prefix_char} where: SET DEF[INE] Is the command, which may be abbreviated to SET DEF. OFF Disables variable substitution. ON Enables variable substitution, and resets the substitution prefix character back to the default ampersand (&) character. Variable substitution is on by default. prefix_char Is the new substitution prefix character. When you start SQL*Plus, variable substitution will be on by default, and the default prefix character is an ampersand. If you are running a script that uses ampersands in text strings, you may want to change the prefix character to some- < previous page page_411 next page > < previous page page_412 next page > Page 412 thing else. If your script does not use substitution variables, you may find it easiest to just turn the feature off completely. SET ESCAPE Use SET ESCAPE to specify the character used to escape the substitution variable prefix: SET ESC[APE] {OFF ¦ ON ¦ escape_char} where: SET ESC[APE] Is the command, which may be abbreviated to SET ESC. OFF Turns the escape feature off completely. SQL*Plus will not recognize any character as an escape character. This is the default setting. ON Enables the escape feature, and resets the escape character back to the default value, a backslash (\). escape_char Is the new escape character. By default, this is a backslash. You use the escape character when you want to place an ampersand in a command and you don't want that ampersand interpreted as a substitution variable prefix character. The following example shows a case where this can be a problem: SQL> SELECT O Reilly & Associates FROM dual; Enter value for associates: The ampersand in front of the word Associates causes SQL*Plus to interpret it as substitution variable name. To work around this behavior, you can turn the escape feature on and precede the ampersand with a backslash. Here is an example: SQL> SET ESCAPE ON SQL> SELECT O Reilly \& Associates FROM dual; O 'REILLY&ASSOCIATES O'Reilly & Associates You can also use the SET ESCAPE command to change the escape character to something other than a backslash. SET SCAN SET SCAN is an obsolete command that allows you to choose whether or not SQL*Plus scans for substitution variables: < previous page page_412 next page > . rows SQL* Plus will return at once from the database. AUTOCOMMIT Controls whether or not SQL* Plus automatically commits your changes. CLOSECURSOR Controls whether or not SQL* Plus keeps the statement. in the Oracle Tuning manual. Among other things, this package controls the contents of the module field in both the V$SESSION and V$SQLAREA views. Whenever you connect to a database, SQL* Plus. the v$session view, as the following example demonstrates: SQL& gt; SELECT module FROM v$session WHERE username=USER; MODULE SQL* Plus SQL* Plus has the ability to update the module name whenever