================================================= DOCUMENTATION NOTES Informix Dynamic Server 7.31.TD1 for Windows NT/2000 DATE: 2 Jan 2001 ================================================= This file describes feature and performance topics either not covered in the manuals or modified since publication. Please examine this file. It contains vital information about application and performance issues. This file contains the documentation notes for the following manuals, in the order listed: Administrator's Guide for Informix Dynamic Server Archive and Backup Guide for Informix Dynamic Server ON-Archive Quick Start Guide DB/Cockpit User Manual DB-Access User Manual Informix Guide to Database Design and Implementation Guide to Informix Enterprise Replication Informix Error Messages Getting Started with Informix Dynamic Server Informix Guide to GLS Functionality Guide to the High-Performance Loader Informix Enterprise Command Center User Guide Informix Enterprise Command Center Installation Guide Installation Guide for Informix Dynamic Server on UNIX Installation Guide for Informix Dynamic Server on Windows NT Informix Storage Manager Administrator's Guide (ISM 2.2) Informix Migration Guide Backup and Restore Guide for Informix Dynamic Server Guide to the Optical Subsystem Performance Guide for Informix Dynamic Server Informix SNMP Subagent Guide Informix Guide to SQL: Reference Informix Guide to SQL: Syntax Informix Guide to SQL: Tutorial Trusted Facility Manual for Informix Dynamic Server ========================================================================= Administrator's Guide for Informix Dynamic Server 7.31 ========================================================================= Table of Contents I. Overview of ADMINDOC_7.3 II. Administrator's Guide for Informix Dynamic Server A. High Availability on Windows NT B. Multiplexed Connections: NETTYPE parameter C. Configuration Parameters (OPT_GOAL, DIRECTIVES, etc.) D. DBSPACETEMP, Explicit Temporary Tables, and Logging E. USEOSTIME Configuration Parameter ((Resolution to PTS # 88775) F. Restoring Blobspaces (Resolution to PTS # 90587) G. onstat -p output for %cached (Resolution to PTS Bug 81165) H. Backing Up After Dropping a Storage Space (Resolution to PTS # 86614) I. Maximum Number of Chunks (Resolution to PTS problem 89532) J. Greater Than 2GB Shared Memory on NT for Dynamic Server 7.31 K. Nonlogging Tables for Dynamic Server 7.31 L. Informix Password Communication Support Module M. Starting Database Server on Windows NT N. Relay Module (Resolution to PTS Bug 104447) O. NETTYPE Configuration Parameter P. Killing a Session (Resolution to PTS Bug 102312) Q. ALARMPROGRAM Default Value Changed =============================== I. OVERVIEW OF ADMINDOC_7.3 ADMINDOC_7.3 describes feature and performance topics not covered in the manuals or modified since publication. Please examine this file. It contains vital information about application and performance issues. =============================== II. Administrator's Guide for Informix Dynamic Server A. High Availability on Windows NT Informix-Dynamic Server, version 7.3, supports high availability on Windows NT. High availability provides protection against single points of failure in database server resources. Informix provides high availability by exploiting Microsofts new subsystems, which are available for Windows NT Server 4.0. These new subsystems enable you to cluster two Windows NT computers, called nodes, as redundant components. When a failure occurs on one node in the cluster, Windows NT restarts the failed applications on the surviving node in the pair. The Microsoft cluster manager and resource manager provide the following capabilities: Failure detection Communication of failure to other subsystems or applications System level recovery Restarting the cluster-aware application on the surviving node An application obtains failure protection by registering a dynamically linked library (DLL) for the high-availability resource with the Windows NT resource manager. The Windows NT resource manager uses the DLL to invoke specific start, restart, stop, and monitoring functions for the resource. A resource is a hardware component, such as a shared disk, or a software application that is shared between the two nodes in a cluster. When a failure occurs on one node, the resource manager moves the resource over to the surviving node and restarts it. Informix Dynamic Server implements high availability by sharing one or more hard disks in a cluster. At any given point in time, only one node owns the shared disks. The other node only accesses the shared disks in the event of failure on the first node. Microsoft's cluster technology includes an administration tool called the Cluster Administrator. The Cluster Administrator enables you to designate a cluster and define resources, resource ownership, and dependencies on other resources. The Cluster Administrator also enables you to define groups that specify resource dependencies, allowing the Resource Manager to move groups of dependent resources to the surviving node in the event of failure. To a client application, the cluster appears to be a single host computer that has one name, the cluster name. The cluster name is equivalent to the machine name. It is not a strict single-system view, however. Each node also has its own name and can have its own private resources. Note that high availability on Windows NT does not require a database server running on each node. Creating an instance of the database server on both nodes simply makes use of the dual nodes. If a node fails, the resource manager restarts the failed database server on the surviving node, regardless of whether a database server is already running there. If a database server is running on the surviving node, then an occasion of multiple residency will exist on that node after the resource manager restarts the failed database server. Any dbspaces that you create on non-shared disks will not have the benefit of high availability. For information on how to implement IDS on a cluster, refer to the README.TXT installation notes. =============================== B. Multiplexed Connections: NETTYPE parameter Chapter 4, "Client/Server Communications", and Chapter 37, "Configuration Parameters", specify that to use a multiplexed connection, you must include in the ONCONFIG file a special NETTYPE parameter that has a value of SQLMUX. This is incorrect. The value must be specified in lowercase, as shown in the following example: NETTYPE sqlmux =============================== C. Configuration Parameters The following configuration parameters are not documented in the Informix-Dynamic Server Administrator's Guide: -------- CDR_DSLOCKWAIT CDR_EVALTHREADS CDR_LOGBUFFERS CDR_QUEUEMEM The CDR_DSLOCKWAIT, CDR_EVALTHREADS, CDR_LOGBUFFERS, and CDR_QUEUEMEM parameters are described in the Guide to Informix Enterprise Replication. -------- DIRECTIVES onconfig.std value 1 range of values 0 or 1 takes effect when shared memory is initialized refer to Informix Guide to SQL: Reference; Informix Guide to SQL: Syntax; Performance Guide for Informix Dynamic Server The DIRECTIVES parameter enables or disables the use of SQL directives. SQL directives allow you to specify behavior for the query optimizer in developing query plans for SELECT, UPDATE, and DELETE statements. Setting DIRECTIVES to 1, which is the default value, enables the database server to process directives. Setting DIRECTIVES to 0 disables the database server from processing directives. Client programs also can set the IFX_DIRECTIVES environment variable to ON or OFF to enable or disable processing of DIRECTIVES by the database server. The setting of the IFX_DIRECTIVES environment variable overrides the setting of the DIRECTIVES configuration parameter. If you do not set the IFX_DIRECTIVES environment variable, all sessions for a client will inherit the database server configuration for processing SQL directives. For more information on the IFX_DIRECTIVES environment variable, refer to the "Informix Guide to SQL: Reference". For more information on SQL directives, refer to the "Informix Guide to SQL: Syntax". For more information on the performance impact of directives, refer to the "Performance Guide for Informix Dynamic Server". -------- ISM_DATA_POOL ISM_LOG_POOL The ISM_DATA_POOL and ISM_LOG_POOL parameters are described in the Backup and Restore Guide for Informix Dynamic Server. -------- OPT_GOAL onconfig.std value -1 range of values 0 or -1 takes effect when shared memory is initialized refer to Informix Guide to SQL: Reference; Informix Guide to SQL: Syntax; Performance Guide for Informix Dynamic Server The OPT_GOAL parameter enables you to specify one of the two following optimization goals for queries: Optimize for FIRST ROWS Optimize for ALL ROWS A value of 0 (zero) sets the optimization goal to FIRST_ROWS. A value of -1 sets the optimization goal to ALL_ROWS, which is the default. When you set the optimization goal to optimize for FIRST ROWS, you specify that you want the database server to optimize queries for perceived response time. In other words, users of interactive applications perceive response time as the time it takes to display data on the screen. Setting the optimization goal to FIRST ROWS configures the database server to return the first rows of data that satisfy the query. When you set the optimization goal to optimize for ALL ROWS, you specify that you want the database server to optimize for the total execution time of the query. Making ALL ROWS the optimization goal instructs the database server to process the total query as quickly as possible, regardless of how long it takes to return the first rows to the application. You can specify the optimization goal in one of four ways: 1) By query (SELECT statement), using the ALL_ROWS and FIRST_ROWS directives 2) By session using the SET OPTIMIZATION statement 3) By environment, through setting of the OPT_GOAL environment variable 4) By database server, through setting the OPT_GOAL configuration parameter The database server determines the optimization goal by examining the settings in the order shown. The first setting encountered determines the optimization goal. For example, if a query includes the ALL_ROWS directive but the OPT_GOAL configuration parameter is set to FIRST_ROWS, the database server will optimize for ALL_ROWS, as specified by the query. For information on the ALL_ROWS and FIRST_ROWS directives and on the SET OPTIMIZATION statement, refer to the "Informix Guide to SQL: Syntax". For information on the OPT_GOAL environment variable, refer to the "Informix Guide to SQL: Reference". For more on the performance issues associated with setting an optimization goal, refer to the "Performnance Guide for Informix Dynamic Server". =============================== D. DBSPACETEMP, Explicit Temporary Tables, and Logging Chapter 13, "Where is Data Stored?" implies that if DBSPACETEMP is set and ample space exists in the temporary dbspaces specified by DBSPACETEMP, explicit tables created with the SELECT . . . INTO TEMP option will be created in one of the listed dbspaces. This is not true, however, in the case of a database with logging. You must include the WITH NO LOG clause with the SELECT . . . INTO TEMP statement to place the explicit temporary tables in the dbspaces listed by DBSPACETEMP. Otherwise, they will be stored as if DBSPACETEMP was not set. For more information on where the database server stores explicit temporary tables when DBSPACETEMP is not set, or when there is insufficient space in the dbspaces listed by DBSPACETEMP, see Chapter 13, "Where is Data Stored?" E. USEOSTIME Configuration Parameter (Resolution to PTS # 88775) This update applies to the section on the "USEOSTIME" configuration parameter on page 33-92. If you set USEOSTIME to 0, the CURRENT function returns a zero (.000) for the YEAR TO FUNCTION field. Example: 1998-09-29 02:20:04.000 For more information on using the CURRENT function to return a DATETIME value, see the SQL Syntax Guide. F. Restoring Blobspaces (Resolution to PTS # 90587, 100943, 83276) This update applies to the section "Why Do You Have to Back Up Logical-Log Files to Free Blobpages" on page 18-22 of the Administrator's Guide. WARNING: Be sure to back up all blobspaces and logical logs containing transactions on simple large objects before stored in a blobspace. If you do not back up these blobspaces and logical logs, you might not be able to restore the blobspace data. Procedure for backing up blobspace data 1. Close the current logical log if it contains transactions on simple large objects in a blobspace. 2. Perform a backup of the logical logs and blobspace as soon as possible after updating simple-large-object data. It does not matter whether you back up the logical logs or blobspaces first. During log backup, the database server uses the data pointer in the logical log to copy the changed text and byte data from the blobspace into the logical log. If you wait until a blobspace is down to perform the log backup, the database server cannot access the blobspace to copy the changed data into the logical log. This blobspace might not be restorable because the log contains data pointers pointing to nonexistent blobspace data. G. onstat -p output for %cached (Resolution to PTS BUG 81165) This update applies to the section "The onstat -p Option" on page 35-84 of the 7.3 Administrator's Guide. Replace the following description of the %cached field "%cached is the percentage of reads cached, calculated as 100 * (buffreads - dskreads)/buffreads. (If dskreads exceeds buffreads, the value is displayed as 0.0)." with the following description: "%cached is the percent of reads cached, calculated as follows: 100 * (bufreads - dskreads) / bufreads If bufreads exceeds the maximum integer (or long) value, its internal representation becomes a negative number, but the value appears as 0.0. H. Backing Up After Dropping a Storage Space (Resolution to PTS # 86614) This information applies to Chapter 14, "Dropping a Dbspace or Blobspace" on page 14-19. If you create a storage space with the same name as the deleted storage space, perform another level-0 backup to ensure that future restores do not confuse the new storage space with the old one. This information applies to the onspaces section on page 35-50. Perform a level-0 backup after you create or drop a storage space. I. Maximum Number of Chunks (Resolution to PTS problem 89532) This information applies to Chapter 13 "Where Is Data Stored" section "Limits on Chunk Size and Number" on page 13-5. Add the following paragraph: "The maximum number of chunks that you can allocate for a given Dynamic Server system is 2048." J. Greater Than 2 GB Shared Memory on NT for Dynamic Server 7.31 To enable the 3 GB shared-memory support, the Windows NT operating system must be the Enterprise Edition. The database server can access shared memory segments greater than 2 gigabytes on Windows NT systems. However, you must enable this feature with an entry in the Windows NT boot file. To add the entry, edit the boot.ini file (located in the toplevel, or root directory). You can either add a new boot option, or use the currently existing boot option. To enable >2 gigabyte support, add the following text to the end of the boot line: /3GB The following example has the >2 gigabyte support enabled: [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows NT Workstation Version 4.00 " /3GB The maximum size of the shared memory segment is dependent upon the operating system, but for Windows NT it is approximately 3 gigabytes. The maximum values for the following configuration parameters have been increased to allow for database servers using larger amounts of shared memory: Parameter Maximum Value _________ ____________ SHMVIRTSIZE 3 gigabytes BUFFERS 2^31 -1 If you allocate more BUFFERS than can be placed in the resident segment, the database server automatically overflows the buffer pool to the virtual segments. K. Nonlogging Tables for Dynamic Server 7.31 You can create logging or nonlogging tables within a logging database on Dynamic Server, Version 7.31. The two table types are STANDARD (logging tables) and RAW (nonlogging tables). The default standard table is like a table created in earlier versions without specifying a special keyword. You can create either a standard or raw table, and alter tables from one type to another. In a nonlogging database, both standard tables and raw tables are nonlogging. In a nonlogging database, the only difference between standard and raw tables is that raw tables do not allow indexes and referential constraints. The following figure lists the properties of the two types of tables available with Dynamic Server. The flag values are the octal values for each table type in the flags column of systables. Characteristic STANDARD RAW ---------------------------------- Permanent Yes Yes Logged Yes No Indexes Yes No Rollback Yes No Recoverable Yes Depends Restorable Yes Depends Loadable Yes Yes Enterprise Repl Yes No Flag Value None 0008 Standard Permanent Tables A standard table is the same as a table in a logged database that the database server creates. All operations are logged, record by record, so standard tables can be restored from a backup and support recoverability and rollback. Enterprise Replication is allowed on standard tables. A standard table is the default type on both logging and nonlogging databases. Standard tables are logged if stored in a logging database but are not logged if stored in a nonlogging database. Raw Tables Raw tables are intended for the initial loading and validation of data. You can use any loading utility such as dbexport or HPL to load raw tables. Once you have loaded the data, you should alter the table to type STANDARD. If an error or failure occurs during loading of a raw table, the resulting data is whatever was on the disk at the time of the failure. Note: You can use HPL in express mode to load raw tables. After you load the table, perform a level-0 backup. Enterprise Replication is not allowed on raw tables. For information on reverting from 7.31, see the section "Reverting From 7.31 to an Older Version When Using RAW Tables" in the Release Notes. Raw tables are nonlogging permanent tables and are similar to tables in a nonlogging database. The database server does not log updates, inserts, and deletes in a raw table. Raw tables do not support indexes, referential constraints, or rollback. You can restore a raw table from the last physical backup if it has not been updated since then. You can recover a raw table if it has not been updated since the previous checkpoint. A raw table has the same attributes whether stored in a logging or nonlogging database. Loading Data Into a Table Dynamic Server creates standard tables that use logging by default. Data warehousing applications can have very large tables which can take a very long time to load. Nonlogging tables are faster to load than logging tables. You can use the CREATE RAW TABLE statement or use ALTER TABLE statement to alter a standard table to raw prior to loading the table. For more information on how to improve the performance of loading very large tables, see the PERFDOC_7.3 documentation notes. For more information on ALTER TABLE, see the SQLSDOC_7.3 documentation notes. Fast Recovery of Table Types The following table discusses fast recovery scenarios for the two table types available with Dynamic Server. Table Type Fast Recovery Behavior ---------- ---------------------- Standard Fast recovery is successful. All committed log records are rolled forward and all incomplete transactions are rolled back. Raw o If a checkpoint completed since the raw table was modified last, all the data is recoverable. o Updates and deletions that occurred after the last checkpoint are lost. The raw table will look like it did at the last checkpoint. o If inserts occurred after the last checkpoint, the raw table might contain empty rows or be corrupted. Backup and Restore of Table Types The following table discusses backup scenarios for the two table types available with Dynamic Server. Table Type Can You Back Up This Table Type? ---------- -------------------------------- Standard Yes. Raw Yes. If you update a raw table, you cannot restore the data unless you have done a level-0 backup. It is not enough to just back up the logical logs. The following table discusses restore scenarios for these table types. Table Type Can You Restore This Table Type? ---------- -------------------------------- Standard Yes. Raw Yes, you can restore a raw table if it has not been updated since the last backup. No, if the raw table has been updated since the last backup, the restored table will be empty or unreadable. This problem occurs because extents are logged but the inserts are not. Note: Avoid restoring a raw table from an old backup because you might end up with an incompletely restored table. The older the backup, the more likely that it is earlier than your most recent update, insertion, or deletion. L. Informix Password Communication Support Module Add the following paragraph to the section "What are Communications Support Services?" on page 4-14: The Informix Password Communications Support Module (PSWDCSM) provides password encryption to protect a password when it must be sent between the client and the database server for authentication. PSWDCSM is available on all platforms. To use password encryption, you must add a line to the CSS/CSM configuration file, concsm.cfg, and add an entry to the options column of the sqlhosts file. The concsm.cfg file must contain an entry for each communications support module that you are using. Add the following text to the end of the section "The $INFORMIXDIR/etc/concsm.cfg file on page 4-26: The concsm.cfg file entry for password encryption has the following format: csmname(lib-paths, "csm-global-option", "csm-connection-options") The csmname variable is the name that you assign to the communications support module. The lib-paths parameter has the following format: "client=lib-path-clientsdk-csm, server=lib-path-server-csm" The lib-path-clientsdk-csm is the full pathname, including the file name, of the shared library that is the CSM of the client, and the client applications use this CSM to communicate with the database server. The CSM is normally installed in $INFORMIXDIR/lib/client/csm. The lib-path-server-csm is the full pathname, including the file name, of the shared library that is the CSM of the database server. The CSM is normally installed in $INFORMIXDIR/lib/csm, and the database server uses the CSM to communicate with the clients. The following restrictions apply to the CSM pathnames: The pathname cannot contain '=', '"' or ',' . White spaces may not be used between '=' and the pathname or between pathname and ',' or '"' unless the white spaces are part of the pathname. The lib-paths parameter can alternatively have the following format: "lib-path-csm" The lib-path-csm is the full pathname, including the file name, of the shared library that is the CSM. In this case, the same CSM is used by both the client applications and the database server. The csm-global option is not used at this time. If you do not specify a connection option, you can omit both the global option and the connection option parameters. Add the following text to the end of section "The Communications Support Module Option" on page 4-45: The following example specifies that the PSWDCSM communications support module will be used for the connection. Currently, there are no options for this module. csm=(PSWDCSM) M. Starting Database Server on Windows NT In various instances within the manual, the method to start the database server on Windows NT is not accurate. Do not use the oninit command to start the database server on Windows NT. Instead, use IECC or the Windows NT Services tool.To start the database with the Services tool, select the database server service and click Start. N. Relay Module (Resolution to PTS Bug 104447) In "Using the Relay Module" section, in the "To prepare this configuration" procedure, step 3a should include the following sentences: "Copy the 7.3 installation's gls directory into the directory where the Version 5.0X product are installed. Otherwise, connection does not work correctly, and the user might receive a -23101 error (Unable to load locale categories)." O. NETTYPE Configuration Parameter 1. In the "NETTYPE" section on page 33-59, replace the third bullet (which describes the third field of the NETTYPE parameter) with the following bullet: "- The expected number of concurrent connections per poll thread" 2. Replace "Number of Poll Threads" section on page 33-59 with the following two sections: Number of Poll Threads This field specifies the number of poll threads for a specific protocol. The default value of poll_threads is 1. If your database server has a large number of connections, you might be able to improve performance by increasing the number of poll threads. In general, each poll thread can handle approximately 200 to 250 connections. The following example illustrates NETTYPE parameters to increase the number of poll threads and decrease the number of connections per poll thread. This example allows up to 60 connections of a shared memory connection: NETTYPE ipcshm,3,20,CPU For more information on monitoring and tuning the number of poll threads and connections, refer to your Performance Guide. Number of Connections This field specifies the maximum number of connections per poll thread that can use this protocol at the same time. The default value of connections is 50. If you know that only a few connections will be using a protocol concurrently, you might save memory by explicitly setting the estimated number of connections. For all net types other than ipcshm, the poll threads dynamically reallocate resources to support more connections as needed. Avoid setting the value for the number of concurrent connections to much higher than you expect. Otherwise, you might waste system resources. For more information on poll threads, refer to network virtual processors in the DSA chapter of the Administrator's Guide. P. Killing a Session (Resolution to PTS Bug 102312) Add an index entry "Killing a session" for page 35-33 which describes how to use onstat -u to first obtain the session id and then use onmode -z session id to kill a session. Q. ALARMPROGRAM Default Value Changed ALARMPROGRAM no longer has a default value in the ONCONFIG file. If you do not set ALARMPROGRAM in the ONCONFIG file, the database server uses the no_log.sh value which disables continuous logical-log backups. If you set ALARMPROGRAM to $INFORMIXDIR/etc/log_full.sh, ON-Bar performs continuous backups for your logical logs. ========================================================================= Archive and Backup Guide for Informix Dynamic Server 7.31 ========================================================================= Table of Contents I. Overview of ARCHIVEDOC_7.3 II. Archive and Backup Guide for Informix Dynamic Server A. Mail Generated When /NONOTIFY Flag Used (Resolution for PTS 34406) B. Corrected BLOCKSIZE Value (Resolution for PTS 81650) C. LBU_PRESERVE Configuration Parameter (Resolution for PTS 101222) =============================== I. OVERVIEW OF ARCHIVEDOC_7.3 ARCHIVEDOC_7.3 describes feature and performance topics not covered in the manuals or modified since publication. Please examine this file. It contains vital information about application and performance issues. =============================== II. Archive and Backup Guide for Informix Dynamic Server A. Mail Generated When /NONOTIFY Flag Used (Resolution for PTS 34406) ON-Archive always generates a mail even if you use the /NONOTIFY flag. Refer to Archive and Backup Guide, Version 7.3, page 8-19, 8-28, and 8-75. B. Corrected BLOCKSIZE Value (Resolution for PTS 81650) The 7.3 Archive and Backup Guide states in Chapter 8, "Archive and Backup Qualifiers, Blocksize," on page 8-68 that the BLOCKSIZE value is an integer from 8197 to 65,024 bytes. The minimum value of 8197 is incorrect. The correct minimum value of BLOCKSIZE should be 32,768. C. LBU_PRESERVE Configuration Parameter (Resolution for PTS 101222) The 7.3 Archive and Backup Guide states in Chapter 13, page 20, "You can either abort the archive to free the tape device and back up the logical logs to continue processing or leave normal processing suspended until the archive completes." The corrected sentence is: "You can either abort the archive (using ctrl -c only) to free the tape device and back up the logical logs to continue processing, or leave normal processing suspended until the archive completes. The archive will complete only if the LBU_PRESERVE configuration parameter is set to 1. For more information about the LBU_PRESERVE configuration parameter, see the Administrator's Guide." ========================================================================= ON-Archive Quick Start Guide 7.31 ========================================================================= Table of Contents I. Overview of ARCHQSDOC_7.3 II. ON-Archive Quick Start Guide A. B. =============================== I. OVERVIEW OF ARCHQSDOC_7.3 ARCHQSDOC_7.3 describes feature and performance topics not covered in the manuals or modified since publication. Please examine this file. It contains vital information about application and performance issues. =============================== II. ON-Archive Quick Start Guide No new information is available at this time. ========================================================================= DB/Cockpit User Manual 7.31 ========================================================================= Table of Contents I. Overview of COCKPITDOC_7.3 II. DB/Cockpit User Manual A. B. =============================== I. OVERVIEW OF COCKPITDOC_7.3 COCKPITDOC_7.3 describes feature and performance topics not covered in the manuals or modified since publication. Please examine this file. It contains vital information about application and performance issues. =============================== II. DB/Cockpit User Manual No new information is available at this time. ========================================================================= DB-Access User Manual 7.31 ========================================================================= Table of Contents I. Overview of DBACCDOC_7.3 II. DB-Access User Manual A. DBACCNOIGN Environment Variable B. DB-Access Incompatibilities =============================== I. OVERVIEW OF DBACCDOC_7.3 DBACCDOC_7.3 describes feature and performance topics not covered in the manuals or modified since publication. Please examine this file. It contains vital information about application and performance issues. =============================== II. DB-Access User Manual A. DBACCNOIGN Environment Variable The DBACCNOIGN environment variable affects the behavior of the dbaccess utility if an error occurs under the one of the following circumstances: a. You run dbaccess in non-menu mode. b. You execute the LOAD command with dbaccess in menu mode. (Informix Dynamic Server with Universal Data option only.) To roll back an incomplete transaction if an error occurs while you run the dbaccess utility under either of the preceding conditions, set the DBACCNOIGN environment variable to 1. Non-Menu Mode Example For example, assume dbaccess runs the following SQL commands: DATABASE mystore BEGIN WORK INSERT INTO receipts VALUES (cust1, 10) INSERT INTO receipt VALUES (cust1, 20) INSERT INTO receipts VALUES (cust1, 30) UPDATE customer SET balance = (SELECT (balance-60) FROM customer WHERE custid = 'cust1') WHERE custid = 'cust1' COMMIT WORK In this example, one statement has a misspelled table name. The receipt table does not exist. If your environment does not have DBACCNOIGN set, dbaccess inserts two records into the receipts table and updates the customer table. The decrease in the customer balance exceeds the sum of the inserted receipts. If DBACCNOIGN is set to 1, the following messages display to indicate that dbaccess rolled back all of the INSERT and UPDATE statements. The messages also identify the cause of the error so that you can resolve the problem. 206: The specified table (receipt) is not in the database. 111: ISAM error: no record found. Error in line 6 Near character position 16 377: Must terminate transaction before closing database. 853: Current transaction has been rolled back due to error or missing COMMIT WORK. Load Statement Example If your application runs on an Informix Dynamic Server with the Universal Data option, you can set DBACCNOIGN to protect data integrity during a LOAD statement, even if dbaccess runs the LOAD in menu-mode. Assume you execute the LOAD statement from the DB-Access SQL menu page. Forty-nine rows of data load correctly, but the fiftieth row contains an invalid value that causes an error. If you set DBACCNOIGN to 1, the database server does not insert the forty-nine previous rows into the database. If DBACCNOIGN is not set, the first forty-nine rows are inserted. =============================== B. DB-Access Incompatibilities Use DB-Access with the current version of an Informix database server. If you use DB-Access with a server from a different version, you may obtain incon-sistent results, such as when you use a version that does not support long identifiers with a version that does support them. ========================================================================= Informix Guide to Database Design and Implementation 7.31 ========================================================================= Table of Contents I. Overview of DDIDOC_7.3 II. Informix Guide to Database Design and Implementation A. Reexecution of a Prepared Statement When the View Definition Changes =============================== I. OVERVIEW OF DDIDOC_7.3 DDIDOC_7.3 describes feature and performance topics not covered in the manuals or modified since publication. Please examine this file. It contains vital information about application and performance issues. =============================== II. Informix Guide to Database Design and Implementation A. Reexecution of a Prepared Statement When the View Definition Changes The following information should be documented in the section "Modifying with a View" on page 8-26. The definition of the view that exists when you prepare a SELECT statement on that view is the one that is used. If the definition of a view changes after you prepare a SELECT statement on that view, the execution of the prepared statement gives incorrect results because it does not reflect the new view definition. No SQL error is generated. ========================================================================= Guide to Informix Enterprise Replication 7.31 ========================================================================= Table of Contents I. Overview of EREPDOC_7.3 II. Guide to Informix Enterprise Replication A. Enterprise Replication Limitations in 7.30 B. Enterprise Replication Features for 7.31 =============================== I. OVERVIEW OF EREPDOC_7.3 EREPDOC_7.3 describes feature and performance topics not covered in the manuals or modified since publication. Please examine this file. It contains vital information about application and performance issues. =============================== II. Guide to Informix Enterprise Replication A. Enterprise Replication Limitations in 7.30 The 7.3 release does not include certain features that are documented in the manual. The 7.3 release has the following limitations: No hierarchical replication No sparse catalogs No floating threads If you attempt to use one of these features, Enterprise Replication responds with an "Unsupported Feature Error." The following paragraphs point out areas of the manual that are affected by the limitations: In "Network Topologies" on page 1-11, the only supported topology is "fully connected." In the Elite Exporters example in Chapter 2, only the fully-connection portion of the network is supported. The fully-connected portion includes only Asia, Australia, Germany, and India. In "Enterprise Replication Topologies" on page 3-8, the only supported topology is fully interconnected. The fully-interconnected topology requires that each database server be a root. In Figure 8-2, "Declare Database Server in Expert Mode," the only server type available is "root." The following cdr define server options, listed on p.11-31, are not available: leaf, sporadic, sparse, nosparse. B. Enterprise Replication Features and Limitations in 7.31 The Version 7.3 manual has the following errors and omissions: + Primary and read-only participant definition options + Definition of time parameter + Limitation on synonyms and views + Invalid option for the -cdr delete server- command + Incorrect statement about DECLARE CURSOR The 7.31 release of Enterprise Replication contains many changes to the underlying structure that make Enterprise Replication operate more efficiently and fix a number of bugs. The following changes are visible to the user: + Changes to server-type definitions + Receive Queue restriction + Updates of TEXT and BYTE columns + Option to use table owner to apply replication + Longer names for replicates and replicate groups + Additions to the Enterprise Replication Manager + Deletion of the Replication Monitor + New ONCONFIG configuration parameters + Changes to the sysmaster (SMI) database + Additions and changes to the error return codes + Changes to GLS codesets The Primary and Read-only Participant Options You can specify the mode of replication by using the P (primary) and R (read only) options with the participant. If you do not specify either P or R for the participants, then the replicate is an update-anywhere replicate. For example, in the following definitions, replicate Rone is update-anywhere, while in replicate Rtwo, serv2 is the primary and serv1 is read-only. cdr define repl -c serv1 -C timestamp -S tran Rone \ "db@serv1:owner.table" "select * from table" \ "db@serv2:owner.table" "select * from table" cdr define repl -c serv1 -C timestamp -S tran Rtwo \ "R db@serv1:owner.table" "select * from table" \ "P db@serv2:owner.table" "select * from table" Definition of Time Parameter Several API functions (Chapter 12) incorrectly state that you can use the "time" parameter to specify the time at which the action should occur. Instead, the action always takes place immediately. In each of the following functions, you should set the time parameter to (time_t)0: cdr_delete_group() cdr_delete_repl() cdr_resume_group() cdr_resume_repl() cdr_resume_serv() cdr_start_group() cdr_start_repl() cdr_stop_group() cdr_stop_repl() cdr_suspend_group() cdr_suspend_repl() cdr_suspend_serv() Limitation on Synonyms and Views The table name used in defining a participant must be the name of an actual table. It cannot be the name of a synonym or a view. This limitation affects the following areas: + Replication Manager pages in the Define Replicate Wizard in the Add Participant Wizard in the Scripting View + The participant definition in the following CLU commands: cdr define replicate cdr modify replicate + The participate definition in the following API functions: cdr_define_repl() cdr_modify_repl() Incorrect statement about DECLARE CURSOR The manual states "You cannot use the $DECLARE cursor CURSOR WITH HOLD with the BEGIN WORK WITHOUT REPLICATION statement." This restriction is no longer true. Invalid option for the -cdr delete server- command The description of the -cdr delete server- command includes the -X or --shutdown option. This option was never implemented. The -cdr delete server- command does a complete shutdown. Changes to Server-Type Definitions This release of Enterprise Replication defines only Root servers. The Replication Manager includes options for defining server types that will be available only in later releases. Previously the defined (although not available) database-server types were Root, Non-Root, Non-Root Server with Sparse Catalog, Intermittent Server, and intermittent Server with Sparse Catalog. This has been simplified to three server types: Root, Nonroot, and Leaf. In this release of Version 7.31, you can choose only the Root server type. Receive Queue Restriction The receive and send queue database space can only be set when the server is defined (using the Replication Manager, the CLU cdr define server command, or the cdr_define_serv() API function). With this change, the database spaces can no longer be changed by: + Server property and scripting view pages in the Replication Manager + cdr modify server CLU command + cdr_modify_serv() API function Updates of TEXT and BYTE Columns In earlier versions, Enterprise Replication did not replicate a TEXT or BYTE column unless that column itself was changed. Now Enterprise Replication replicates the TEXT or BYTE column when the row qualifies for update. Option to Use Table Owner to Apply Replication The O (owner) option in the participant definition causes permission checks for owner to be applied to the operation (such as insert or update) that is to be replicated and to all actions fired by any triggers. When the O option is omitted, all operations are performed with the privileges of user informix. This option affects the following areas: + Replication Manager pages: in the Define Replicate Wizard in the Replicate Property Sheet in the Scripting View + CLU commands, participant definition in: cdr define replicate cdr modify replicate cdr change replicate + API functions, participant definition in: cdr_define_repl() cdr_modify_repl() cdr_change_repl() For example, the following CLU command specifies that the permission checks should use the table owner: cdr define repl -c serv1 -C timestamp -S tran Rone \ "O db@serv1:owner.table" "select * from table" \ "O db@serv2:owner.table" "select * from table" Longer Names for Replicates and Replicate Groups Replicate names and replicate-group names may now be 128 bytes long. Previously, the limit on length was 18 bytes. (In English, one character is one byte, but in some languages one character uses multiple bytes. The limit is always calculated in bytes.) However, the longer replicate and group names do not work with earlier versions of Enterprise Replication. If you are using both Version 7.31 and earlier versions, limit your names to 18 bytes. Additions to the Replication Manager In addition to the changes already listed, the 7.31 Version of the Enterprise Replication Manager includes a new Generic Replication Wizard. The Generic Replication Wizard is most useful in the following situation: + All databases to be replicated have identical attributes (that is, all databases have the same database name, owner, and table name). + You are starting a new replication system. When you start a new replication system, you can use the Generic Replication Wizard to quickly prepare all of the replicates that you might need. Then, if needed, you can modify those replicates that need special attention. Even if the database attributes are different, you can still use the Generic Wizard. The wizard sets up the replicates as if the attributes were identical. You can then use the scripting view to modify the replicates to change the non-identical attributes. To use the Generic Replication, choose New Script or Open Script from the File menu on the main Replication Manager page. Then choose Generic Configuration Wizards from the Object menu of the Replication Scripting View. Select either the Update-Anywhere or Primary Target model. After selecting a model, you specify the tables and columns that should be replicated. The wizard then creates a replicate for each table and column that includes all of the selected servers. Deletions from the Replication Manager The Replication Monitor, which was a separate tool that you could access from the Replication Manager, is no longer being supported. That option is not available in Version 7.31. New ONCONFIG Configuration Parameters Version 7.31 has the following new configuration parameters in the ONCONFIG configuration file: + CDR_LOGDELTA + CDR_NIFCOMPRESS + CDR_NIFRETRY + CDR_NUMCONNECT CDR_LOGDELTA specifies the percent of space reserved for logical logs that can be devoted to memory for the send and receive queues. The default value is 30. If the evaluation of transactions for replication is much slower than the actual rate of transactions, the evaluation can fall considerably behind. In that case, Enterprise Replication blocks out further transactions to let the transaction evaluation catch up. If your log size is small, you can increase CDR_LOGDELTA to prevent the database server from overcommitting queue memory during this catch up phase. You can also use CDR_QUEUEMEM to limit the memory that the database server uses for the send and receive queues. The database server uses the lower of the values derived from CDR_QUEUEMEM and CDR_LOGDELTA. CDR_NIFCOMPRESS (CDR Network Interface Compression) specifies the level of compression that the database server uses before sending data from the source database server to the target database server. Network compression saves network bandwidth over slow links, but uses more CPU to compress and decompress the data. The possible values are -1 = never compress, 0 compress only if the target server expects compression, 1 through 9 specify increasing levels of compression. The default value is 0. CDR_NIFRETRY specifies the time in seconds between retries when the database server is trying to make a connection for Enterprise Replication. The default value is 300 seconds. If the values is 0, the database server does not retry the connection. Retry happens only if the connection goes down abnormally. A graceful shutdown of a server does not cause a retry. CDR_NUMCONNECT specifies the estimated number of Enterprise Replications that the database server expects to make. This estimate helps the database server allocate resources; it does not restrict the actual number of connections that the database server is able to make. The default value is 16. Changes to the sysmaster (SMI) Database The section summarizes the changes have been made to the sysmaster database. + syscdrrecv remove entire table + syscdrpart add column: usetabowner + syscdrq remove columns: bytesqueued, lstcommittime, lastquetime + syscdrqueued remove columns: bytesqueued, lstcommittime, lastquetime + syscdrs drop columns: issporadic, sendq, recvq, atsdir, risdir change column: issparse -> isleaf add column: isnotroot + syscdrserver drop column: issporadic change column: issparse -> isleaf add column: isnotroot + syscdrtx drop columns avgrcvlat, avgcmtlat + syscdrtxproc drop columns avgrcvlat, avgcmtlat Additions and Changes to the Error Return Codes The following error return codes for Enterprise Replication have been changed or added: Error Error Meaning Mnemonic Number 34 /* not in use */ CDR_EPARENT 72 Cannot delete server with children CDR_ESPAROOT 73 Leaf-root configuration not allowed 74 /* not used */ CDR_ELIMITED 75 Request denied on limited server CDR_EMSGFORMAT 76 Unsupported message format CDR_EDROPDB 77 Couldn't drop syscdr database (sqlerr -425) CDR_EATSDIR 78 ATS directory does not exist CDR_ERISDIR 79 RIS directory does not exist CDR_ECRCHANGE 80 Illegal conflict resolution change CDR_EUDTBADCOL 81 UDT collection types not allowed CDR_EUDTEXPR 82 UDTs not allowed in expressions (such as where clauses) CDR_ENOUDTPKEY 83 No UDTs in primary key allowed CDR_ESYNC 84 No sync server with non-root & leaf CDR_EPARTFLAGS 85 Incorrect participant flags CDR_ELEAF 86 Conflicting leaf server flags or attempt to sync with leaf server CDR_ESTOPFLAGS 87 Invalid cdr stop options 88 /* not in use */ CDR_EMODRECVQ 89 Cannot modify dbspace for queues CDR_ECLOCKSKEW 90 System clocks are out of synchronization CDR_ESERVSTATE 91 Invalid server state transition 99 /* not in use */ CDR_EINVSYNC 102 Root server cannot sync with non-root or leaf servers CDR_EINVCONNECT 103 Invalid server to connect CDR_ETEMPDB 104 Cannot use temp dbspaces for Send/Recv Queues Changes to GLS Codesets When used with IECC 3.01, the graphical user interface, Enterprise Replication Manager, requires the UTF8 locales and conversion files. ========================================================================= Informix Error Messages 7.31 ========================================================================= Table of Contents I. Overview of ERRDOC_7.3 II. Informix Error Messages A. ON-Bar Error Messages =============================== I. OVERVIEW OF ERRDOC_7.3 ERRDOC_7.3 describes feature and performance topics not covered in the manuals or modified since publication. Please examine this file. It contains vital information about application and performance issues. =============================== II. Informix Error Messages A. ON-Bar Messages For the complete list of ON-Bar informational, warning, and error messages with corrective actions, see the ONBARDOC_7.3 documentation note. ========================================================================= Getting Started with Informix Dynamic Server 7.31 ========================================================================= No new information is available at this time. ========================================================================= Informix Guide to GLS Functionality 7.31 ========================================================================= No new information is available at this time. ========================================================================= Guide to the High-Performance Loader 7.31 ========================================================================= Table of Contents I. Overview of HPLDOC_7.3 II. Guide to the High-Performance Loader A. Loading of Raw Tables B. Corrections/Bugs =============================== I. OVERVIEW OF HPLDOC_7.3 HPLDOC_7.3 describes feature and performance topics not covered in the manuals or modified since publication. Please examine this file. It contains vital information about application and performance issues. =============================== II. Guide to the High-Performance Loader A. Loading of Raw Tables You can use HPL in express mode to load raw tables. After you load the table, perform a level-0 backup. =============================== B. Corrections/Bugs 1) 96273 The description of the 'and' operator in Appendix D is incorrect. The correct description is: Constructs a comparison of two or more items. Matches only if the data record fields match all of the comparisons. Note that the comparisons can only be applied to one field. For example, if you are matching on a field named Income, the match condition > 5000 and <> 6000 selects all the records with income greater than 5000, but not a record of 6000. 2) - - The description of the <=value on page D-2 is incorrect. The correct description is: Matches if the data-record field is less than or equal to the specified value. For example, if you are matching on a field named Income, the match condition <= 50000 selects all records whose Income field contains an entry 50,000 or less. Character strings must be delimited by quotes (<= "Jones"). 3) 87728 The -fv option is not supported in deluxe mode. Choosing this option gives the following error: no-violations generation, option not valid in deluxe mode. 4) 105088 Running onpload with the -fd option fails when data is loaded from a tape device if the tape device name is not Berkeley Software Distribution (BSD) compliant. ========================================================================= Informix Enterprise Command Center User Guide 7.31 ========================================================================= No new information is available at this time. ========================================================================= Informix Enterprise Command Center Installation Guide 7.31 ========================================================================= No new information is available at this time. ========================================================================= Installation Guide for Informix Dynamic Server on UNIX 7.31 ========================================================================= Table of Contents I. Overview of INSTLUXDOC_7.3 II. Installation Guide for Informix Dynamic Server on UNIX A. Tar and cpio commands B. Incorrect error messages =============================== I. OVERVIEW OF INSTLUXDOC_7.3 INSTLUXDOC_7.3 describes feature and performance topics not covered in the manuals or modified since publication. Please examine this file. It contains vital information about application and performance issues. =============================== II. Installation Guide for Informix Dynamic Server on UNIX A. Tar and cpio commands Step 3 in the procedure for loading the product source files (p. 6) omits examples of the tar and cpio commands. On some operating-system platforms you can use the following tar command to place the product files in the current directory: tar xvf filename In this command is the pathname of the tar file that contains the product files for the database server. On some operating-system platforms you can use the following cpio command to place the product files in the current directory: cpio -icdumvB < filename In this command is the pathname of the cpio file that contains the product files for the database server. B. Incorrect error messages Two of the error messages on p. 16 (under the heading "Product Installation Failures") are incorrect. These error messages are only valid for installation of 9.1x and later servers. They would never appear in the installation of 7.3x servers. Please ignore these messages as they falsely imply that you should perform the install as user informix. First message: ------------- Problem. When you attempt an installation, you see the following message. Please rerun this installation procedure as the informix user. Solution. Check that you are logged in as informix. Second message: -------------- Problem. After you enter the six-letter key,the script displays a message similar to one of the following examples: chmod: can't change filename etc/brand: cannot open filename filename: not owner Solution. This problem usually occurs because you loaded the product source files as user root. If you plan to install the product onto an existing installation, log out and log back in as informix. Reload the product source files...and repeat all subsequent steps... ========================================================================= Installation Guide for Informix Dynamic Server on Windows NT 7.31 ========================================================================= Table of Contents I. Overview of INSTLNTDOC_7.3 II. Installation Guide for Informix Dynamic Server on Windows NT A. Cluster Installation For Informix Dynamic Server B. Correction to Figure for Installation Wizard Main Page C. Stopping Services before Uninstalling the Database Server D. Stopping Services before a Fresh Silent Install E. Error in Storage_Size Parameter in Playback File =============================== I. OVERVIEW OF INSTLNTDOC_7.3 INSTLNTDOC_7.3 describes feature and performance topics not covered in the manuals or modified since publication. Please examine this file. It contains vital information about application and performance issues. =============================== II. Installation Guide for Informix Dynamic Server on Windows NT A. Cluster Installation For Informix Dynamic Server (IDS) Version 7.3 If you want to use the Cluster Server feature with IDS, follow the following installation procedure; if not, use the procedure documented in the Informix Dynamic Server Installation Guide. a) Start Cluster Administratoror b) Create a New Group in Cluster Administrator for IDS c) Add /Create Dependent Resources to Informix Group d) Creating New Resources e) Install Informix Dynamic Server f) Create Informix Resource g) Set Resource Property h) Initialize the Server Through the Command Line i) Create Additional Dbspaces j) Uninstalling the Server k) Reinstalling the Server l) Domain Install Without Administrator Privileges on the PDC a) Start Cluster Administrator ============================== Click Start, point to Programs, point to Administrative Tools (Common), and then click Cluster Administrator. Notes: When you start Cluster Administrator, connections left open when you closed the previous session are restored. If no connections were left open, Cluster Administrator prompts you to enter a cluster name, a node, or an IP address before it displays any information. To open a connection to a cluster, you can use the network name or IP address of either the cluster or one of its nodes. If Cluster Administrator cannot find the cluster by its name, try entering the name of an active node in the cluster. b) Create a New Group in Cluster Administrator for Informix Dynamic Server ========================================================================== 1 On the File menu, point to New, and then click Group. 2 In Name, type a name for the new group (e.g. Informix Database). 3 In Description, type any comments you want, and then click Next. 4 Under All Nodes in the Cluster, click the nodes you want to be the preferred owners for the group, and then click Add. 5 Click Move Up and Move Down as needed to change the priority of a selected owner. 6 When the preferred owners list is complete and prioritized, click Finish. Notes: The name that you give the group is only for administrative purposes. It is not the same as the Network Name, which is the UNC resource that identifies the group in the browse list. The group description appears along with the group name when the group is listed in the right pane of Cluster Administrator. All resources within the new group will fail over together. To have the group fail back to a node, specify that node as the preferred owner. Groups may be balanced between two nodes to maximize the performance of the cluster. However, you may choose not to have a preferred owner if the location of the group does not greatly affect performance. c) Add /Create Dependent Resources to Informix Group ==================================================== Through examples, define what are dependent resources. List down typical dependent resources which will always be there, eg: disk drives which host dbspaces, ip address, etc. 1. Add Shared drives to the group: Those drives where root and other dbspaces will be stored would need to be made part of Informix Group. Similarly the drive in which Informix binaries are installed should also be made member of Informix group. 2. Create an IP address resource and network name resource in Informix group: Network name resource is the name [of virtual host] which will be used in SQLHOST. Client applications when they connect to dbserver will be talking to the network name resource [virtual host] rather than to any physical machine name. For cluster configurations, virtual host names are used in SQLHOST. As opposed to physical host name, the virtual host names persist even after failure of a node, because upon failure they simply move over to the surviving node during failover. The IP address resource created here would be the IP address to which the network name resource will be bound. Because this IP address migrates from one node to another during failover, it is also called a floating IP address. To create an IP and Network Name resource, use the procedure described in "Creating New Resources". d) Creating New Resources ========================= 1. Select the Informix Resource Group: In the left or right pane of Cluster Administrator, click the newly created Informix group to which you want the resource to belong. 2. Choose New Resource: On the File menu, point to New, and then click Resource. 3. Setup New Resource: In the New Resource dialog box, do the following. In Name, type a unique name for the resource. In Description, type a description for the resource (optional). In Resource Type, enter the appropriate type.(e.g, IP address, Network Name, Informix Database Server etc.) In Group, enter the name of newly created Informix group to which the resource will belong. If you want to have this resource monitored separately from others, select the Run this resource in a separate Resource Monitor check box. 4. Click Next. 5. Setup Owner of the resource: Add or remove possible owners of the resource, and then click Next. 6. Add dependencies: under Available resources, click a resource, and then click Add. (For example, Network Name resource is dependant on IP address resource; Informix Database Server resource depends on Network Name and shared disk resources .) 7. Repeat step 6 for any other resource dependencies, and then click Next. 8. Enter resource-specific information, and then click Finish. Notes: Before adding a resource to your cluster, you must verify the following: That the type of resource is either one of the basic types recognized by MSCS or one created by using an appropriate .dll file provided by the resource manufacturer. That a group already exists within the cluster to which your resource will belong. That all dependent resources have been created. A separate Resource Monitor is recommended for a resource whose .dll file is likely to conflict with other resource .dll files. Separate Resource Monitors are also recommended for resources that will have to be debugged. e) Install Informix Dynamic Server ================================== 1. Install Informix DS on both nodes. 2. Create Dbspace on Shared Drives which are added in Informix group. 3. Specify Network Name resource name as the name of virtual host to which IDS clients will be connecting. 4. Do not initialize IDS when installer prompts you for it. f) Create Informix Resource =========================== IDS installation for a cluster automatically sets up a new resource type definition for IFMXDB. After IDS installation, the cluster administrator can be used to create new resources of type IFMXDB. Create New resource of type IFMXDB using the procedure described in section D. Note: Use Informix Server Name as the name of resource that you will create in this step. If you want to deploy multiple instances of IDS then each instance of IDS would require its own resource group, and its own IFMDB resource within that. The IFMXDB resources should always be named same as the informix server name for that instance. g) Set Resource Property ======================== Set Resource Property ServerInstance after creating the IFMXDB resource. Use the following command in command shell \Cluster directory to set property parameter (ServerInstance Name): \Cluster\CLUSTER RES /PRIV ServerInstance= Where INFORMIXSERVER is like e.g. ol_njcluster12 which is also the resource name. h) Initialize the Server Through the Command Line ================================================= After the server has been installed on both nodes and resource dependencies in the Informix resource group have been set up, initialize the engine using the Sevice Control panel with the -iy parameter. Note: There is no failover support during engine initialization phase. i) Create Additional Dbspaces ============================= If you will be using additional dbspaces, create them on those disk drives which you have already put under informix resource group. Note: There is no failover support during creation of additional dbspaces. j) Uninstalling the Server ========================== The server uninstallation would remove files only when the previous version is uninstalled before attempting to reinstall or upgrade. Otherwise, the uninstall would not remove any files. The uninstall displays various dialog boxes. The message server is a shared component and different versions of the server could be using the same message server. Therefore, uninstall does not remove the message server. If it is not required, it can be stopped using the Services Control Panel. After that, use deletes.exe in the informix directory to remove the service: deletes msgserv After this, the uninstall can be performed. The uninstallation process displays various dialog boxes. The first one displays three options: (1) Remove server executables and support files (2) Remove server files and databases (3) Remove server executables and revert registry to 7.2x format The first one removes only the installed files. It leaves the registry, groups etc. as they are. This can be used if you plan to perform a reinstall or an upgrade. One thing that you may want to do is shut down SNMP service if it is running. Also make sure that the OnSNMP process that runs from %INFORMIXDIR%\bin directory has terminated. This process stays on for a while after the engine has terminated and the SNMP service is stopped, depending on the linger time set in registry. The second option removes all of the executable files as well as database files. This option can be used if you do not want the database server at all. You would lose all data when this option is chosen. The third option is to be used only when you upgraded from an earlier version (7.2x or 7.1x) of the server. This is similar to option 1 in that it only removes the executables and support files but leaves the databases around. In addition, some changes made while upgrading are undone. Before selecting the third option, make sure you have performed the steps necessary for revert. These are documented in the release notes. Also remember to shutdown the SNMP service and wait for the OnSNMP.exe to terminate as indicated for option 1. Note that the OnLine service that is created after reversion contains an incorrect password. The password can be changed using the Services Control Panel by selecting the Startup button. k) Reinstalling the server ========================== When re-installing IDS 7.3 upon a previous installation of server, stop the Server Agent service before starting the installation. l) Domain Install Without Administrator privileges on the PDC ============================================================== The 7.30 version of install can perform a domain install when the logged in user does not have administrative privileges on the domain controller. However, the user still needs administrative privileges on the machine where the installation is being performed. In that cases, following actions need to be performed before an install is performed. (1) Create all required users and groups and assign appropriate privileges. Also insert the users in appropriate groups. This can be done by someone who has the required privileges to create users and groups in the domain. If role separation is not enabled, create a domain user "informix". Also create a domain group "Informix-Admin". Make user informix part of the group Informix-Admin. This can be done using the User Manager for Domains. If role separation is desired then additional groups and users need be created and made members of the corresponding groups as well. The groups are for the roles of Database Administrators, Auditing Administrators, Security Administrators and Database Users (the default names are Informix-Admin, ix_aao, ix_dbsso and ixUsers). Also create two users which are part of the ix_aao and ix_sso group respectively (the default user names are AAO and DBSSO). You can, of course, select existing users and groups during installation instead of creating new users and groups. However, user "informix" is required. Note, however, that all users are required to be direct membembers of the group. Indirectly including members in a group by including another group would not work. The following actions are to be taken on the local machine where installation is taking place. This can be done by the person performing the install since the installer needs local administration privileges. Make the domain user informix a member of the administrators group on the local machine. Also grant these advanced privileges to the informix user - "Logon as service", "Run as part of OS", "increase quotas" and "Replace a process level token". These privileges can be granted using the user manager application and selecting the Policies->User Rights menu item. (2) Logon to the machine as a domain user. This can be the user informix created above. Run the installation program. If role separation is enabled, the passwords of the ix_aao and ix_dbsso user need not be specified, since the users are already created. Rest of the installation procedure remains the same. B. Correction to Figure for Installation Wizard Main Page In Figure 1 on page 9 (The Installation Wizard Main Page), the text for the first option is incorrect. This text should read: 1) Select installation options and supply data C. Stopping Services before Uninstalling the Database Server In the "Uninstalling the Database Server" section, the following paragraph needs to be added after the first paragraph on p. 20: After uninstalling the database server, you must stop all Informix-related services and ISM services. Otherwise you will encounter problems when you try to perform a fresh install of the database server. D. Stopping Services before a Fresh Silent Install After the first paragraph on p. 21, the following text needs to be added to the "Silent Install" topic: If you plan to perform a fresh silent install, you must stop all Informix-related services and ISM services after uninstalling the database server. That is, no Informix-related services or ISM services should be running before you perform a fresh silent install. E. Error in Storage_Size Parameter in Playback File The description of the Storage_Size parameter on p. 28 in the "Server Instance Parameters" section is incorrect. The text states that this parameter specifies the size of the additional dbspace in kilobytes. In fact this parameter specifies the size of the additional dbspace in megabytes. ========================================================================= Informix Storage Manager Administrator's Guide 7.31 ========================================================================= Table of Contents I. Overview of ISMDOC_7.3 II. Informix Storage Manager Administrator's Guide A. ISM Setup Information B. ISM Administrator Runs on Windows 95 Consoles C. NSRADMIN Utility D. Uninstalling ISM Before Installing Networker E. ISM 2.0 Information =============================== I. OVERVIEW OF ISMDOC_7.3 ISMDOC_7.3 describes feature and performance topics not covered in the manuals or modified since publication. Please examine this file. It contains vital information about application and performance issues. =============================== II. Informix Storage Manager Administrator's Guide A. ISM Setup Information For information on the following items, see the SERVERS_7.3 release-notes file: o ISM setup on UNIX and Windows NT database servers o ISM Administrator GUI setup o ISM configurations not using ISMData pool B. ISM Administrator Runs on Windows 95 Consoles The ISM Administrator graphical user interface runs on Windows 95 consoles as well as Windows NT consoles. This information was omitted from the manual. C. NSRADMIN Utility The NSRADMIN character-based user interface is not intended for use by the end user unless instructed to do so by Informix Technical Support. Incorrect use of these tools could result in problems with your ISM system. These tools are undocumented. D. Uninstalling ISM Before Installing Networker Users migrating to Legato Networker should invoke: ism_shutdown -deinstall to remove the /nsr directory of ISM which will conflict with Networker. This invocation will also stop the ISM daemons. (Refer to PTS # 92055.) E. ISM 2.0 Information ISM 2.0, which is Year 2000 compliant, is included with IDS 7.31 on UNIX. For more information, see the SERVERS_7.3 release- notes file. ISM 2.0 also includes the new ism_chk.pl command. ism_chk.pl ---------- The ism_chk.pl command collects information about the current state of ISM, ON-Bar processes, and the database server from various log files and utility programs. The ism_chk report is useful when you are investigating backup or restore problems. Although the ism_chk.pl command displays the report on the screen, you can redirect them to a file. The ism_chk.pl command is a perl program that runs on both UNIX and Windows NT. Syntax Description ------------------ ism_chk -> -------------------------------------------------------------------| \ -s / \ -e / \ -m / \-w/ \-v/ -s Allows you to input a date and time range for scanning the logs. Enter the date and time to begin scanning the logs. If omitted, the default start date and time is "1980-01-01 00:00:00". Use double quotes only if you include the time in the range. -e Allows you to input a date and time range for scanning the logs. Enter the date and time to end scanning the logs. If omitted, the default end date and time is "2999-12-31 23:59:59". Use double quotes only if you include the time in the range. -m Specifies the maximum number of lines for the log report. Choose this feature when the logs are large or you only need certain parts of the report. The default is 999999 lines. -w html Formats the output as HTML for display with a web browser. Set on to use HTML output. The default is HTML off. The web output includes a table of contents with links to various sections of the report: environment variables log file list Informix database server log ON-Bar activity log ON-Bar debug log ISM daemon log ISM message log ISM savegrp log ISM XBSA log ISM save set report bootstrap verification report sysutils generated bootstrap onstat output network status report ISM resource report directory of executables -v verbose Displays progress messages while the report is being constructed and outputs the report to the screen. Set on to use verbose mode. The default is quiet mode that outputs the report to the screen. Specifying the Start and End Times for the Log Report ----------------------------------------------------- If you select a narrow time interval for the ism_chk report, it is easier for you to find the information that you need in the various logs. For example, to produce a report on the logs for a time period from 8 A.M., January 1, 1999 to 9 P.M., January 2, 1999, you would specify: ism_chk.pl -s "1999-01-01 08:00:00" -e "1999-01-02 21:00:00" A shorthand way of specifying the start and end times is: ism_chk.pl -s "1999-01-01 08" -e "1999-01-02 21" For example, to produce a report on the logs for all day January 3, you would specify: ism_chk.pl -s 1999-01-03 -e 1999-01-04 Contents of the ism_chk Report ------------------------------- The following list describes the contents of each section of the ism_chk report. To specify the date and time range for the log information, use the -s and -e options. Environment variables -- Lists the important environment variables that affect oninit, ISM, and ON-Bar. Log file list -- Lists the full path names of the various logs that contain information about ISM and ON-Bar operations. Database server log -- Lists the text from this log. ON-Bar activity log -- Lists the text from this log. ON-Bar debug log -- Lists the text from this log. ISM daemon log -- Lists the text from this log. ISM message log -- Lists the text from this log. ISM savegrp log -- Lists the text from this log. ISM XBSA log -- Lists the text from this log. ISM save set report -- Lists all the save sets currently in the ISM catalogs. Bootstrap verification report -- Verifies that the dbspaces and logical logs that are in the ON-Bar bootstrap file are also in the ISM catalog. sysutils generated bootstrap -- Re-creates the ON-Bar bootstrap file that is generated from the ON-Bar catalogs. onstat -a output -- Displays the output of onstat -a that shows the state of the database server. For more information, see the onstat section of the utilities chapter in the "Administrator's Guide." Network status report -- Displays the output of the netstat utility that reports on network load and resources. ISM resource report -- Lists the ISM resource file that contains definitions for storage devices and volumes, and the retention policies for stored objects. Directory of executables -- Lists the contents of the Informix executables directory. Use this output to verify the software version. Sample ism_chk Verbose Output ----------------------------- The following sample output is from the ism_chk command with the -v verbose flag set. The -m option limits the report to the last 10 lines of the logs The report is written to an ascii file, my_ism_report: $ perl ism_chk.pl -v -m 10 > my_ism_report ism_chk: checking ISM/Onbar/Online logs -s 1980-01-01 00:00:00 -e 2999-12-31 23:59:59 -m 10 lines will be displayed -v report output selected checking ISM resources... checking ONCONFIG ONCONFIG.ol_mazama28... checking Online log... checking Bar Activity Log... checking Bar Debug Log... checking ISM daemon log... checking Message log... checking Savegrp log... checking ISM catalog for ssid's... checking Onbar catalog for ISM ssid's... checking Onstat... checking Network status... ism_chk: all done now. ism_chk -s starttime -e endtime -s starttime -m maxlines -w -v ========================================================================= Informix Migration Guide 7.31 ========================================================================= Table of Contents I. Overview of MIGRATEDOC_7.3 II. Informix Migration Guide A. Reverting from a 7.24 or Later Database Server: In-Place ALTER TABLE Statements B. Migrating with the Informix Enterprise Command Center (IECC) C. Using Compatible Versions of Applications and the Database Server for Shared Memory D. Migrating from ON-Tape or ON-Archive to ON-Bar E. Migrating to or from Dynamic Server 7.3x with Enterprise Replication (ER) Modifying SQL Statements Before Reversion Changing or Retaining the ER State F. Enabling Greater Than 2GB Shared Memory on Windows NT for Dynamic Server 7.31 G. Using Nonlogging Raw Tables to Load Data Faster H. Updating Statistics After Reversion to Dynamic Server 7.30 I. Migration Between OnLine Dynamic Server 7.1x and Dynamic Server 7.3x J. Migration Between 7.2x Database Servers K. New Environment Variable in Dynamic Server 7.31 L. Migration Issues in Release Notes M. Saving a Copy of the sm_versions File Before Migration =============================== I. OVERVIEW OF MIGRATEDOC_7.3 MIGRATEDOC_7.3 describes migration topics that the "Informix Migration Guide" does not cover or that have changed since publication of the guide. Please examine this file. It contains vital information about migration issues. =============================== II. Informix Migration Guide A. Reverting from a 7.24 or Later Database Server: In-Place ALTER TABLE Statements The clause "(or later)" on the second line, first paragraph, is missing in the following section in the "Informix Migration Guide," February 1998, page 5-38. Modify In-Place ALTER TABLE (Version 7.24 and Later) Upgrading to the database server, Version 7.24, and later occurs automatically. However, reverting from Version 7.24 (or later) is not possible if outstanding In-Place ALTER TABLEs exist. An In-Place ALTER TABLE is outstanding when data pages exist with the old definition. If you attempt to revert to a previous version, the code checks for outstanding alter operations and lists any that it finds. You need to update every row of each table in the outstanding alter list with an ALTER TABLE version and then perform the reversion. If an In-Place ALTER TABLE was performed on a table, you can convert the older version pages to the latest version by running a test UPDATE statement. For example, run the following test UPDATE statement: UPDATE tab1 SET column1 = column1 For more information on In-Place ALTER TABLE, see your "Performance Guide." One way to determine if a table has an In-Place ALTER TABLE that is outstanding would be to run the following command: oncheck -pT tablename Part of the output of this command shows the count of pages for each version of the table (Home Data Page Version Summary). If there are any pages that are not current, there is an In-Place ALTER TABLE that is outstanding on the table. B. Migrating with the Informix Enterprise Command Center (IECC) Instructions for migrating with the Informix Enterprise Command Center (IECC) interface might not be up-to-date as of publication of the "Migration Guide," Version 7.3. For correct steps for using IECC, refer to the "Informix Enterprise Command Center User Guide," Version 3.0. C. Using Compatible Versions of Applications and the Database Server for Shared Memory If you set your application (such as ESQL/C) to use shared-memory communication protocols, you must use a version of the application that is compatible with your database server. D. Migrating from ON-Tape or ON-Archive to ON-Bar If you migrate from ON-Tape or ON-Archive to ON-Bar, or if you change or upgrade storage managers, refer to the documentation notes for the "Backup and Restore Guide." E. Migrating to or from Dynamic Server 7.3x with Enterprise Replication (ER) When you migrate (upgrade to or revert from) Dynamic Server 7.3x, the syscdr database migrates to your target database server version, along with the sysmaster and sysutils databases and system tables. Modifying SQL Statements Before Reversion ========================================= Before you revert from Dynamic Server 7.3x to OnLine Dynamic Server 7.2x, modify SQL SELECT statements that are larger than 255 bytes in the partdef table. The reversion process truncates these SELECT statements so that they fit into the older version's table definitions. Before you use ER on the target database server, fix any SQL SELECT statements that were truncated. Changing or Retaining the ER State ================================== When you revert from Dynamic Server 7.31 to Dynamic Server 7.30 or OnLine Dynamic Server 7.2x or from Dynamic Server 7.30 to OnLine Dynamic Server 7.2x, the reversion process places ER in an INACTIVE state. To change the ER state to ACTIVE, after you bring up the older database server, type the following command: start_cdr When you upgrade to Dynamic Server 7.31 from Dynamic Server 7.30 or OnLine Dynamic Server 7.2x or to Dynamic Server 7.30 from OnLine Dynamic Server 7.2x, the ER state is the same as it was in the older database server. Note: If you revert to OnLine Dynamic Server 7.20, first drop the syscdr database because OnLine Dynamic Server 7.20 does not support Continuous Data Replication or ER. F. Enabling Greater Than 2GB Shared Memory on Windows NT for Dynamic Server 7.31 Dynamic Server, Version 7.31 can access shared memory segments larger than 2 gigabytes in a Windows NT environment. To use the Greater Than 2GB Shared Memory feature, you need to enable it with an entry in the Windows NT boot file, as the ADMINDOC_7.3 documentation notes describe. The maximum values for the following configuration parameters are larger in Dynamic Server 7.31 to allow for database servers using larger amounts of shared memory: Parameter Maximum Value --------- ------------- SHMVIRTSIZE 3 gigabytes BUFFERS 2^31 -1 G. Using Nonlogging Raw Tables to Load Data Faster You can use nonlogging raw tables in a logging database to speed up the initial loading and validation of data in Dynamic Server, Version 7.31. Dynamic Server creates standard tables that use logging by default. Data warehousing and other applications can have very large tables that take a long time to load. Nonlogging tables are faster to load than logging tables. To create a nonlogging table for loading, you can use the CREATE RAW TABLE statement, or you can use the ALTER TABLE statement to alter the table type from STANDARD to RAW. Tables of type RAW do not allow indexes or referential constraints, so the initial loading is faster than with tables of type STANDARD. After the loading of a raw table is complete, you can change it to a logging table (in a logging database) by altering the table type to STANDARD. Then you can use ALTER TABLE statements to add referential constraints to the table and CREATE INDEX statements to add indexes. For more information on these SQL statements, refer to the "Informix Guide to SQL: Syntax." To load raw tables, you can use any data loading utility, such as dbimport, or HPL in express mode. After you load data, you should perform a level-0 backup. Before you modify any data in a raw table or use it in a transaction, you should alter the table type to STANDARD. If an error or failure occurs during the loading of a RAW table, the resulting data is whatever was on the disk at the time of the failure. The dbexport and dbschema utilities support the CREATE RAW TABLE and ALTER TABLE ... TYPE (RAW) statements. For more information on nonlogging tables in Dynamic Server 7.31, see the ADMINDOC_7.3 documentation notes. For information on reverting nonlogging raw tables from version 7.31, see the release notes in the SERVERS_7.3 file. For more information on how to improve the performance of loading very large tables, see the PERFDOC_7.3 documentation notes. For more information on the ALTER TABLE statement, see the SQLSDOC_7.3 documentation notes. H. Updating Statistics After Reversion to Dynamic Server 7.30 After a reversion from Dynamic Server 7.31 to Dynamic Server 7.30, you need to run the following statement to rebuild all the query plans for the 7.30 database server: UPDATE STATISTICS FOR PROCEDURE; This statement reoptimizes all procedures for the database server. The time required to execute this statement depends on the number of procedures. I. Migration Between OnLine Dynamic Server 7.1x and Dynamic Server 7.3x Although the "Migration Guide" says that you need to upgrade to OnLine Dynamic Server 7.2x before you can upgrade to Dynamic Server 7.3, direct migration is possible between OnLine Dynamic Server 7.1x and Dynamic Server 7.3x. Before upgrading to 7.3x, you should apply all service patches to the 7.1x database server. In the "Informix Migration Guide", February 1998, Figure 1-2 on Page 1-6 and Figure 1-3 on Page 1-7 do not indicate that you can migrate from all 7.1x versions directly to version 7.3. These figures should indicate all of the direct migration paths between 7.1x and 7.3. They should also show that you can migrate from OnLine 5.x directly to Dynamic Server 7.3x. When you migrate to a new database server, be sure to check that the version of your storage manager has been validated for the new database server. If it has not, you might need to upgrade your storage manager as well. J. Migration Between 7.2x Database Servers Migration between different versions of 7.2x database servers works the same way as migration from 7.2x to 7.3. See Chapter 5, "Migrating the Database Server 6.0 or Later to 7.3," or the "Informix Migration Guide," February 1998, and the next paragraph. Taking an archive on one version of a 7.2x database server, such as 7.23, and restoring it on a later database server, such as 7.24, does not work. Migration involves a series of steps that Chapter 5 describes in detail. The beginning of the chapter says "This chapter describes the procedures to migrate between Informix Dynamic Server, Version 7.3, and versions 6.0 and later. You can use the same procedure to upgrade to Version 7.2, 7.22, 7.23, or 7.24." When you migrate to a new database server, be sure to check that the version of your storage manager has been validated for the new database server. If it has not, you might need to upgrade your storage manager as well. K. New Environment Variable in Dynamic Server 7.31 (PTS 99945) Dynamic Server, Version 7.31 introduces the IFX_NETBUF_PVTPOOL_SIZE environment variable to control the maximum size of a private network buffer pool. L. Migration Issues in Release Notes Check the release notes for new SQL reserved words, the procedure for upgrading from ISM 1.0 to ISM 2.0, and other information that might help you migrate your database server to Dynamic Server 7.31. M. Saving a Copy of the sm_versions File Before Migration Before you upgrade to a later version of the database server, save a copy your current sm_versions file, which should be in the $INFORMIXDIR/etc or %INFORMIXDIR%\etc directory. If you are using a different directory as INFORMIXDIR for the new database server, copy sm_versions to the new $INFORMIXDIR/etc or %INFORMIXDIR%\etc directory, or copy sm_versions.std to sm_versions in the new directory, and then edit the sm_versions file with appropriate values before starting the upgrade. ========================================================================= Backup and Restore Guide for Informix Dynamic Server 7.31 ========================================================================= Table of Contents I. Overview of ONBARDOC_7.3 II. Backup and Restore Guide for Informix Dynamic Server A. Using onsmsync to Expire and Synchronize the Backup History B. Ensuring That Needed Devices Are Available C. Handling the XBSA Shared Library for AIX D. Changing Storage Managers with ON-Bar E. Moving from ON-Tape or ON-Archive to ON-Bar F. Using a Different ISM Storage Pool Name G. Using Imported Parallel Restores H. Changes Made to Physical Restore and Log Salvage I. Performing a Point-in-Time Restore in a Non-English Locale J. Backing Up After Adding a New Storage Space K. Correction to Appendix B L. Migrating ON-Bar Scripts M. Using Fake Backups in a Data Warehouse N. Performing External Restore of Critical Dbspaces O. Miscellaneous Corrections (PTS Resolutions) P. Using ON-Bar to Initialize High-Availability Data Replication Q. The bargroup Group (UNIX) R. ALARMPROGRAM Default Value Changed (UNIX) S. ON-Bar Messages =============================== I. OVERVIEW OF ONBARDOC_7.3 ONBARDOC_7.3 describes feature and performance topics not covered in the manuals or modified since publication. Please examine this file. It contains vital information about application and performance issues. =============================== II. Backup and Restore Guide for Informix Dynamic Server A. Using onsmsync to Expire and Synchronize the Backup History ON-Bar is a suite of utilities for backing up and restoring Informix Dynamic Server databases. ON-Bar cooperates with a storage manager to perform these tasks. ON-Bar and the storage manager communicate via the XBSA interface. ON-Bar maintains a history of backup and restore operations in the sysutils database and an extra copy of the backup history in the "emergency boot file." The sysutils database is used for normal recovery operations when only a portion of the data is lost (warm restore). The boot file is used only for cold restores during disaster recovery. Use the onsmsync utility in IDS 7.31 to perform the following tasks: 1. Expires old ON-Bar backup objects. 2. Allows the storage manager to tell ON-Bar that a backup object has expired according to its own internal policy. So ON-Bar does not ask the storage manager to restore backup objects that are no longer available. 3. By deleting unwanted backup objects, onsmsync prevents unbounded growth in the sysutils database and emergency boot file. 4. Regenerates a corrupted emergency boot file. The onsmsync utility removes the following items from the sysutils database and emergency boot file: o Backup objects that the storage manager has expired according to its own policy. o Old backup objects based on the age of the backup. o Old backup objects based on the number of times they have been backed up. You also can use onsmsync to regenerate a corrupted emergency boot file or to synchronize the sysutils database. Use onsmsync with the database server on-line or in quiescent mode to synchronize both the sysutils database and the emergency boot file. If the database server is off-line, onsmysnc synchronizes the storage manager with the emergency boot file. To synchronize the sysutils database, bring the database server on-line and run onsmsync. The onsmsync command performs the following operations to synchronize the sysutils database, the storage manager, and the emergency boot file: o Adds backup history to sysutils that is in the emergency boot file but is missing from the sysutils database. o Removes the records of restores, whole-system restores, fake backups, external backups, and failed backups or restores from the sysutils database. o Removes the records of whole-system backups based on the number of generations, retention date, or interval. o Expires old logical logs that are no longer needed. o Regenerates the emergency boot file from the sysutils database. Choosing an Expiration Policy ----------------------------- You can choose from the following three expiration policies: o Retention date (-t) deletes all backup objects before a particular date and time. o Retention interval (-i) deletes all backup objects older than some period of time. o Retention generation (-g) keeps a certain number of versions of each backup object. ON-Bar always retains the latest level-0 backup for each storage space. It expires all level-0 backups older than the specified time unless they are required to restore from the oldest retained level-1 backup. ON-Bar expires all level-1 backups older than the specified time unless they are required to restore from the oldest retained level-2 backup. ON-Bar retains a whole-system backup that starts before the specified retention time and ends after the specified retention time. Using the onsmsync Command -------------------------- The order of the commands does not matter except that the dbspace names or filename must come last. Tip: Use the BAR_HISTORY configuration parameter to control whether the sysutils database maintains a backup and restore history. onsmsync ____________________________________________________________________ | | | | | | | | | |\_ -g _/| \_ -O _/ |\_ -f _/| | | | | | | | | | | | | | | |\_ -t