Upgrading to Informix 12.10

Understanding the new, enhanced, and discontinued features in Informix 12.10 to better plan the upgrade

IBM® Informix® version 12.10.xC1 comes with striking new features and enhancements in existing features—as well as a few features or products that were removed. Understanding the new, enhanced, and discontinued features is crucial for better planning and determining which functions should be disabled or enabled during the upgrade process. This minimizes the impact of conversion/reversion and results in a smooth upgrade to Informix 12.10. This article provides all the necessary information to help database administrators make an informed decision on setting the 12.10 features during conversion and then changing the settings, if needed, after the upgrade. The article also covers the required steps in case a reversion is needed.

Sergio Dias (sdias@us.ibm.com), Software Engineer, IBM

Photo of Sergio DiasSergio Dias is a software engineer with several certifications in IBM Informix and DB2 database servers, and over 30 years of experience in hardware and software development, consulting, technical support, and software quality assurance (QA). Sergio currently works in the Informix QA team on High Availability and Data Replication technologies and leads the Smooth Upgrade team.



25 April 2013

Introduction

The Informix 12.10 family of products consists of the database server, client products, datablade modules, development and administration tools, and many more.

  • Informix servers
    • IBM Informix 12.10.xC1
  • Client products
    • IBM Informix Client Software Development Kit (Client SDK), version 4.10.xC1
    • IBM Informix Connect, version 4.10.xC1
    • IBM Informix JDBC Driver, version 4.10.JC1
    • IBM Data Server Driver for JDBC and SQLJ, version 3.59
    • IBM Data Server Driver for ODBC and CLI, version 10.1.2
    • IBM Data Server Provider for .NET, version 10.1.2 (Windows™ only)
    • IBM Informix DataBlade® Developers Kit (DBDK), version 4.20.xC1
    • IBM Informix BladeManager, version 4.20.xC1
  • DataBlade modules
    • IBM Informix Excalibur Text Search DataBlade, version 1.31.xC1
    • IBM Informix Web DataBlade Module, version 4.13.xC4
    • Sample spatial data disks
  • Globalization components
    • IBM Informix GLS, version 6.00.xC1
    • IBM Informix International Language Supplement, version 3.50.MC7
  • Informix tools
    • IBM Informix 4GL, version 7.50.xC6
    • IBM Informix Genero®, version 2.41
    • IBM OpenAdmin Tool (OAT) for Informix, version 3.11, which includes the following plug-in components:
      • IBM Informix Health Advisor Plug-in for OAT
      • IBM Informix Replication Plug-in for OAT
      • IBM Informix Schema Manager Plug-in for OAT
      • IBM Informix TimeSeries Plug-in for OAT
    • IBM Mobile OpenAdmin Tool for Informix, version 1.1
  • Informix solutions
    • IBM Informix Warehouse Accelerator, version 12.10.xC1
    • IBM Informix SQL Warehousing Tool, version 11.50 (supported by Informix 11.50.xC3 and later versions)
  • Informix virtual images
    • IBM Informix 12.10.xC1 Virtual Appliance
  • Additional IBM software

    The following IBM products are provided in the package of some Informix editions. You can learn more about these products on ibm.com®.

    • IBM Cognos® BI 10.2
    • IBM Data Studio 3.2
    • IBM Mobile Database 7.0
    • IBM Mobile Database Sync 1.0
    • IBM SPSS® Desktop 21
    • IBM SPSS Modeler 15

The scope of this article is to cover the upgrade impact that is related to the IBM Informix Database Server 12.10.xC1 and the IBM Informix Client SDK 4.10.xC1 in comparison to Informix Database Server 11.70.xC7 and Informix Client SDK 3.70.xC7.

In case you are upgrading from a version prior to 11.70.xC7, consult the Infocenter website for the versions 10.00, 11.10, 11.50, or 11.70, and visit the Product Overview section to learn more about other features that might have upgrade impact. See Resources for Infocenter links.

This article covers the migration paths to Informix 12.10, the conversion guard, the new SQL keywords, the removed features or products, and an overview of new and enhanced features, with information to help database administrators accomplish a smooth upgrade to Informix 12.10.

This article does not replace or act as a substitute for the IBM Informix documentation, so for further details see Resources for documentation links.


Migration paths

This section describes the migration paths to Informix 12.10.

Types of migration

The Informix database server has basically two types of migrations: in-place and non-in-place.

  • In-place migration (Upgrade)

    In-place migration, or simply upgrade, is a process where you install a new version of the product in a different location from your current version on the same machine, copy your configuration file, and add new parameters, as needed. Then, when you start the Informix instance, the database data is automatically converted to the new version.

    This method also includes the in-place downgrade, where the database data is automatically reverted to the old version.

    Throughout this article, when conversion/reversion is mentioned, it refers to in-place upgrade/downgrade.

  • Non-in-place migration (Migration)

    Non-in-place migration, or simply migration, is used when moving to a new version of the Informix product on a different machine with different architectures, page sizes, optimization of dbspaces, or extent allocations in comparison to the old version. This is a more complex process that requires more planning and setup time compared to upgrading on your existing computer because it requires that you modify and copy the database schema, user data, and user objects from one server to another server.

Migration to Informix 12.10

Following are the migration paths to Informix 12.10:

  • If you are on version 11.70, 11.50, 11.10, or 10.00, you can upgrade directly to Informix 12.10 on the same operating system.
  • If you are on earlier versions of the database server that do not support direct upgrade, consider these options:
    • Upgrade to an earlier, interim version of the database server that supports direct upgrade to 12.10 before you upgrade to Informix 12.10. Refer to the migration information that is included in the documentation set for the interim version of the database server.
    • Migrate to Informix 12.10, installing it in a new location, and then use the dbexport and dbimport utilities or distributed SQL to move your data into the new database server.

If necessary, you can revert to the version of the database server from which you upgraded; however, you cannot revert to any other version of the database server.

If you have a high-availability cluster or if you use Enterprise Replication, you must coordinate the migration of all servers involved in high-availability clusters or Enterprise Replication. Follow additional procedures to upgrade your servers from the IBM Informix Migration Guide. See Resources for a link.

After successful migration to Informix 12.10, you must complete a series of post-migration tasks to prepare the new version of the server for use. For further details, see the IBM Informix Migration Guide. See Resources for a link.

Note: Starting with Informix 12.10, the support to directly upgrade from versions 7.31 and 9.40 to the new Informix 12.10 was removed.


Conversion Guard

This section describes the Conversion Guard, a feature available since Informix 11.50.xC6 that can be used to quickly restore the database server to a consistent, pre-upgrade state if the upgrade to a new Informix server fails.

By default, the CONVERSION_GUARD configuration parameter is enabled and a temporary directory is specified in the RESTORE_POINT_DIR configuration parameter, as shown in Listing 1.

Listing 1. Conversion Guard parameters in the ONCONFIG
##################################################################
# Conversion Guard Related Configuration Parameters
###################################################################
# CONVERSION_GUARD - To turn on conversion guard feature.
#                  - 0 - Off,
#                  - 1 - On, Abort conversion on Conversion Guard error,
#                  - 2 - On, Continue conversion; ignore Conversion
#                        Guard error
# 
# RESTORE_POINT_DIR - The directory, which stores the Conversion Guard
#                   - feature generated files. 
###################################################################

CONVERSION_GUARD 2
RESTORE_POINT_DIR $INFORMIXDIR/tmp

Before beginning an upgrade, consider turning on CONVERSION_GUARD with value of 1 (Abort conversion on Conversion Guard error) or value of 2 (Continue conversion; ignore Conversion Guard error). If an upgrade fails, run the onrestorept utility to restore the Informix instance back to its original state just before the start of the upgrade.

Also, make sure RESTORE_POINT_DIR specifies a directory with enough space. Otherwise, the Conversion Guard operation may fail because of insufficient space to store restore point data. In this case, if the upgrade fails, you might have to restore the database by using a level-0 archive.

Even if you enable the CONVERSION_GUARD configuration parameter, you should still make a level-0 backup of your files in case you need to revert after a successful upgrade or in case a catastrophic error occurs and you cannot revert.


New SQL keywords

Informix 12.10 supports the following new SQL keywords that might affect the migration of your applications, if an application declares the same string as the identifier of a database object. Review these keywords against your applications before upgrading to Informix 12.10.

Listing 2. New SQL Keywords
ACOSH                  FOLLOWING              LAST_VALUE             RATIO_TO_REPORT
ASINH                  EXCEPT                 LEAD                   ROLLING
ATANH                  G                      M                      ROWNUMBER
CHR                    GB                     MB                     ROW_NUMBER
CLUSTER_TXN_SCOPE      GIB                    MIB                    SELECT_GRID
COMPRESSED             GRID                   MINUS                  SELECT_GRID_ALL
CUME_DIST              GRID_NODE_SKIP         NTILE                  SYS
DEFAULTESCCHAR         INTERSECT              NULLS                  T
DENSERANK              K                      PERCENT_RANK           TB
DENSE_RANK             KB                     PRECEDING              TIB
DISCARD                KIB                    RANK                   UNBOUNDED
FIRST_VALUE            LAG                    RATIOTOREPORT

Removed features or products

Starting with Informix 12.10.xC1 the following features or products are not included in the Informix Editions.

  • ON-Monitor
  • Informix Storage Manager
  • Optical subsystem
  • Geodetic DataBlade module
  • Object Interface for C++

Overview of new and enhanced features

This section presents an overview for the following features that may have upgrade impact.

The IBM OpenAdmin Tool for Informix is installed by default with the Client SDK

The IBM OpenAdmin Tool (OAT) for Informix is installed by default during a typical installation of the following products:

  • IBM Informix Client SDK, version 4.10
  • IBM Informix Connect, version 4.10

In previous versions, OAT was not installed by default, so if you do not want to install OAT, use the custom installation option and deselect the OpenAdmin Tool options.

Listing 3. OAT options
    [ ] IBM Informix OpenAdmin Tool
     |-[ ] IBM Informix Replication Plug-in for OpenAdmin Tool
     |-[ ] IBM Informix Schema Manager Plug-in for OpenAdmin Tool
     |-[ ] IBM Informix TimeSeries Plug-in for OpenAdmin Tool
     |-[ ] IBM Informix Health Advisor Plug-in for OpenAdmin Tool

This feature is documented in the IBM Informix Client Products Installation Guide. See Resources for a link.

64-bit ODBC applications

If you have a 64-bit ODBC application that was compiled and linked with a version of IBM Informix Client SDK that is prior to version 4.10, you must recompile the application after migrating.

The SQLLEN and SQLULEN data types were changed to match the Microsoft™ 64-bit ODBC specification. Be sure to analyze any functions that take either of these types to ensure that the correct type passes to the function. This is crucial if the type is a pointer. Also note that in the ODBC specification, some parameters that were previously SQLINTEGER and SQLUINTEGER were changed to SQLLEN or SQLULEN.

Conversion impact: You might need to recompile ODBC applications after converting.

Autonomic storage management for rolling window tables

Tables that use a RANGE INTERVAL distributed storage strategy that also includes the rolling window clause are called rolling window tables.

For those tables, the database server creates new fragments automatically when an inserted record has a fragment key value outside the range of any existing fragment. Depending on the rolling window clause, the database server enforces a purge policy for archiving or deleting interval fragments after the table exceeds a user-specified limit on its allocated storage space size or on the number of its interval fragments. A new built-in Scheduler task runs periodically to enforce the purge policies on qualifying rolling window tables.

Conversion impact: Any existing databases will require a new syspurge() procedure, and existing sysadmin databases will require one new task.

Reversion impact: You must alter the table, removing this feature before reverting. Also, the procedure and the sysadmin task will be dropped if going back to a version where the DB Scheduler exists.

This feature is documented in the IBM Informix Guide to SQL: Syntax. See Resources for a link.

Enhanced CREATE TABLE and ALTER FRAGMENT interval fragment syntax

For tables that are fragmented by RANGE INTERVAL, you can create an SPL routine to return a dbspace name. If this UDF is a function expression after the STORE IN keywords of the interval fragment clause, the database server calls the UDF when it creates new interval fragments for the table. As an alternative to a list of dbspaces, this syntax is valid for interval fragments of rolling window tables or for interval fragments of tables with no purge policy.

Reversion impact: You must alter table, removing this feature before reverting.

This feature is documented in the IBM Informix Guide to SQL: Syntax. See Resources for a link.

The IBM Informix SPL language now includes the CASE statement

SPL routines now can use the CASE statement as a faster alternative to IF statements to define a set of conditional logical branches that are based on the value of an expression. This syntax can simplify migration to Informix of SPL applications that were written for Informix Extended Parallel Server or for other database servers.

Reversion impact: You must drop the SPL routines with CASE statements before reverting.

This feature is documented in the IBM Informix Guide to SQL: Syntax. See Resources for a link.

Enhanced support for OUT and INOUT parameters in SPL routines

SPL user-defined routines and C user-defined routines with OUT or INOUT arguments can be invoked from other SPL routines. The OUT and INOUT return values can be processed as statement-local variables or as local SPL variables of SQL data types. The SPL routines that are invoked from SPL routines support all data types except BYTE, TEXT, BIGSERIAL, SERIAL, and SERIAL8. The C routines that are invoked from SPL routines support all data types except BYTE, TEXT, BIGSERIAL, SERIAL, SERIAL8, and ROW.

Reversion impact: You must drop the SPL routines using this feature before reverting.

This feature is documented in the IBM Informix Guide to SQL: Syntax. See Resources for a link.

Improve space utilization by compressing, repacking, and shrinking B-tree indexes

You can use SQL administration API commands or CREATE INDEX statements to save disk space by compressing B-tree indexes. You can also use SQL administration API commands to consolidate free space in a B-tree index, return this free space to the dbspace, and estimate the amount of space that is saved by compressing the indexes.

Reversion impact: You must drop a compressed index before reverting.

Index compression is documented in the IBM Informix Administrator's Reference, the IBM Informix Administrator's Guide, and the IBM Informix Guide to SQL: Syntax. See Resources for a link.

Save disk space by compressing simple large objects in dbspaces

You can use SQL administration API commands to save disk space by compressing simple large objects (TEXT and BYTE data types) that are stored in the same partition in the same dbspace as the table in which they are referenced. When you run an SQL administration API compress or uncompress command, the database server compresses both the table row data and the referenced simple large objects. You can choose to compress or uncompress only the table row data or only the referenced simple large objects.

Conversion impact: Informix 12.10 will perform several operations, depending on the previous version and the existence of dictionary table.

Reversion impact: You must uncompress the simple large objects before reverting. Also, Informix 12.10 will perform several operations, depending on the previous version.

The compression of simple large objects in dbspaces is documented in the IBM Informix Administrator's Reference and the IBM Informix Administrator's Guide. See Resources for a link.

Save disk space by enabling automatic data compression

You can use the COMPRESSED keyword with the CREATE TABLE statement to enable the automatic compression of large amounts of in-row data when the data is loaded into a table or table fragment. Then when 2,000 or more rows of data are loaded, the database server automatically creates a compression dictionary and compresses the new data rows that are inserted into the table.

Also, when you run SQL administration API create dictionary and compress commands on existing tables and fragments, you enable the automatic compression of subsequent data loads that contain 2,000 or more rows of data. If you run an uncompress command, you disable automatic compression.

In addition to saving space, automatic compression saves time because you do not have to compress the data after you load it.

Conversion impact: Informix 12.10 performs system catalog changes to reflect whether a table is set for auto compression.

Reversion impact: Reverting from 12.10 to 11.70 will affect the system catalogs related to tables. If a table is set for auto compression in 12.10, it will be unset during reversion.

This feature is documented in the IBM Informix Administrator's Reference, the IBM Informix Administrator's Guide, and the IBM Informix Guide to SQL: Syntax. See Resources for links.

Enhanced built-in storage management for backup and restore

IBM Informix Primary Storage Manager (PSM), which replaces IBM Informix Storage Manager (ISM), is easier to set up and use, even in embedded environments. You use the Informix onpsm utility to manage storage for ON-Bar backup and restore operations, including parallel backups, that use file devices (disks).

The onsmsync utility provides new commands that you can use to export backups to, and import them from, Informix PSM external device pools.

Listing 4. PSM-related parameters in the ONCONFIG
# BAR_XFER_BUF_SIZE   - The size, in pages, of each data buffer.
#                       Acceptable values are 1 through 15 for 
#                       4 KB pages and 1 through 31 for 2 KB pages.
#                       If PSM is the storage manager, higher values
#                       can be used.
...
###################################################################
# Primary Storage Manager (PSM) Configuration Parameters
###################################################################
# PSM_ACT_LOG         - The ON-Bar activity log file location.
#                       Do not use the /tmp directory. Use a
#                       directory with restricted permissions.
#                       If not set the value of BAR_ACT_LOG is used.
# PSM_DEBUG_LOG       - The PSM debug log file location.
#                       Do not use the /tmp directory. Use a
#                       directory with restricted permissions.
#                       If not set the value of BAR_DEBUG_LOG is used.
# PSM_DEBUG           - The debug level for PSM. Acceptable
#                       values are 0 (off) through 9 (high).
#                       If not set the value of BAR_DEBUG is used.
# PSM_CATALOG_PATH    - The directory that will hold the PSM catalog
#                       The default is $INFORMIXDIR/etc/psm.
# PSM_DBS_POOL        - The Pool where to place dbspace data.
#                       The default is "DBSPOOL"
# PSM_LOG_POOL        - The Pool where to place log data.
#                       The default is "LOGPOOL"
#
###################################################################

PSM_DBS_POOL    DBSPOOL
PSM_LOG_POOL    LOGPOOL
Listing 5. ISM parameters removed from the ONCONFIG
###################################################################
# Informix Storage Manager (ISM) Configuration Parameters
###################################################################
# ISM_DATA_POOL - Specifies the name for the ISM data pool
# ISM_LOG_POOL  - Specifies the name for the ISM log pool
###################################################################

ISM_DATA_POOL ISMData
ISM_LOG_POOL ISMLogs

Conversion impact: If you were using ISM with the old Informix version, then plan in advance the configuration of Informix PSM to perform a level-0 archive after successfully upgrading to Informix 12.10.

Reversion impact: If you were using ISM with the old Informix version, make sure you saved the ISM administrative files to perform any necessary restore.

Informix PSM and the onsmsync utility are documented in the IBM Informix Backup and Restore Guide. See Resources for a link.

Dynamically configure the database server

You can dynamically configure the database server by:

  • Using the new AUTO_TUNE configuration parameter to enable or disable all automatic tuning.
  • Dynamically modifying many configuration parameters by using the onmode command, OAT, or the SQL administration API commands.
  • Dynamically exporting, importing, and modifying a group of configuration parameters (onmode -we/-wi)

You can view more information about parameters, including current values, valid ranges, and parameter descriptions with onstat commands (onstat -g cfg).

Listing 6. New text in the ONCONFIG that includes the AUTO_TUNE parameter
###################################################################
#
# AUTO_TUNE    - The value of this parameter serves as the default value for
#                the following AUTO_* parameters:
#                AUTO_AIOVPS
#                AUTO_CKPTS
#                AUTO_REPREPARE
#                AUTO_STAT_MODE
#                AUTO_READAHEAD
#                AUTO_LRU_TUNING
#
# Any of the above parameters that are not present in your config file
# will default to the value of AUTO_TUNE, which can be set to either 0 or 1.
# If an AUTO_* parameter is set in your config file, the given value overrides
# that of AUTO_TUNE. Information on individual AUTO_* parameters is below.
#
# AUTO_LRU_TUNING - Enables (1) or disables (0) automatic LRU tuning, which
#                   adjusts flushing thresholds for individual buffer pools
#                   if the server discovers they are sub-optimal
# AUTO_AIOVPS     - Enables (1) or disables (0) automatic management
#                   of AIO VPs
# AUTO_CKPTS      - Enables (1) or disables (0) monitoring of
#                   critical resource to trigger checkpoints
#                   more frequently if there is a chance that
#                   transaction blocking might occur.
# AUTO_REPREPARE  - Enables (1) or disables (0) automatically
#                   re-optimizing stored procedures and re-preparing
#                   prepared statements when tables that are referenced
#                   by them change. Minimizes the occurrence of the
#                   -710 error.
# AUTO_STAT_MODE  - Enables (1) or disables (0) update statistics
#                   automatic mode. In automatic mode, statistics of
#                   table, fragment or index are rebuilt only if existing
#                   statistics are considered stale. A table, fragment
#                   or index can change by STATCHANGE percentage before
#                   its statistics are regarded as stale.
#
# RA_PAGES & RA_THRESHOLD have been replaced with AUTO_READAHEAD.
#
# AUTO_READAHEAD mode[,readahead_cnt]
#     mode              0 = Disable     (Not recommended)
#                       1 = Passive     (Default)
#                       2 = Aggressive  (Not recommended)
#     readahead_cnt     Optional        Range 4-4096
#                       readahead_cnt allows for tuning the # of
#                       pages that automatic readahead will request
#                       to be read ahead. When not set, the default
#                       is 128 pages.
#
#     Notes:
#     The threshold for starting the next readahead request, which
#     used to be known as RA_THRESHOLD, is always set to 1/2 of the
#     readahead_cnt. RA_THRESHOLD is deprecated and no longer used.
#
# If RA_PAGES & AUTO_READAHEAD are not present in the ONCONFIG file,
# AUTO_READAHEAD will default to the value of AUTO_TUNE.
#
# If RA_PAGES is present in the ONCONFIG file and AUTO_READAHEAD is
# not, Informix will set AUTO_READAHEAD to AUTO_TUNE,RA_PAGES
#
###################################################################

AUTO_TUNE 1

An unknown parameter in your ONCONFIG file will now produce the message shown in Listing 7 during startup.

Listing 7. Example of message with deprecated ONCONFIG parameter
attn: Ignoring unknown or deprecated config parameter (RA_THRESHOLD)

Conversion impact: Consider using Informix 12.10 ONCONFIG parameters as close as possible to the parameters of the previous version to minimize issues after conversion; that is, use AUTO_TUNE with value 0 (zero) and then explicitly configure all other AUTO_* parameters. After successfully upgrading, you can dynamically set ONCONFIG parameters to tune your instance.

This feature is documented in the IBM Informix Administrator's Reference, the IBM Informix Administrator's Guide, and the IBM Informix Embeddability Guide. See Resources for links.

Store R-tree indexes in dbspaces with non-default page sizes

When you create an R-tree index, you can specify to store the index in a dbspace with a non-default page size. Previously, R-tree indexes required dbspaces with the default page size.

Reversion impact: You must drop the R-tree indexes in dbspaces with non-default page sizes before reverting.

This feature is documented in the IBM Informix R-tree Index User's Guide. See Resources for a link.

Easily propagate external files through a grid

You can propagate external files that are in a specific directory to other servers in the grid by running the ifx_grid_copy() procedure. For example, if a grid has 50 servers, you can copy an executable file from one server to the other 49 servers by running one procedure.

This feature uses the value of GRIDCOPY_DIR from ONCONFIG as a staging directory.

Listing 8. GRIDCOPY_DIR parameter in the ONCONFIG
#
# GRIDCOPY_DIR              Staging Directory for the ifx_grid_copy
#                           procedure.
#

GRIDCOPY_DIR    $INFORMIXDIR

Conversion impact: If you upgrade servers in a grid from 11.70 to 12.10, and you want to copy external files to servers in the grid, you must enable the ability to copy external files by running the cdr modify grid command with the --enablegridcopy option.

Reversion impact: Before reverting from Informix version 12.10 to an earlier version of Informix, you must disable the ability to copy external files by running the cdr modify grid command with the --disablegridcopy option.

This feature is documented in the IBM Informix Enterprise Replication Guide. See Resources for a link.

Replicate tables without primary keys or ERKEY columns

Enterprise Replication requires a unique key to replicate data. Previously, Enterprise Replication required that the replicated table definition included a primary key or the ERKEY shadow columns. ERKEY columns require extra storage space. You can now specify the columns in a unique index as the replication key or allow Enterprise Replication to assign a primary key, ERKEY columns, or a unique index as the replication when you define the replicate.

Reversion impact: You must delete the replicate that was defined using this feature before reverting.

This feature is documented in the IBM Informix Enterprise Replication Guide. See Resources for a link.

Simplified setup of a data consolidation system

In a data consolidation system, multiple primary servers that contain different data replicate to one target server. The target server does not replicate any data. You can easily set up a data consolidation replication system by defining a replicate and specifying that the primary servers are participants that send only data. Previously, you would configure this type of data consolidation system by defining a different replicate for each primary server.

Reversion impact: You must delete the server as a participant from all send-only replicates before reverting.

This feature is documented in the IBM Informix Enterprise Replication Guide. See Resources for a link.

Replicates are mastered by default

By default, Enterprise Replication replicates are master replicates. If you do not specify a master server with the --master option, the master replicate is based on the first participant. A master replicate uses saved dictionary information about the attributes of replicated columns to verify that participants conform to the specified schema. To create a classic replicate, which does not verify the schemas of participants, include the --classic option in the cdr define replicate command.

Conversion impact: This is not really a conversion issue; however, if you have shell scripts to define replicates, you will need to review them and possibly update them by adding the --classic option.

This feature is documented in the IBM Informix Enterprise Replication Guide. See Resources for a link.

Replicate sensor data

Starting with Informix 12.10, you can replicate TimeSeries instances with Enterprise Replication. For example, if you collect sensor data in multiple locations, you can consolidate the data to a central server.

Set the CDR_TSINSTANCEID configuration parameter to a different value on every replication server to ensure that TimeSeries instance IDs do not overlap.

Listing 9. CDR_TSINSTANCEID parameter in the ONCONFIG
#
# CDR_TSINSTANCEID          Server specific unique id to make timeseries instance
#                           id unique across all Enterprise Replication servers.
#                           Acceptable values are: 0 (default) through 32768.

CDR_TSINSTANCEID 0

Reversion impact: You must delete the server as a participant from all TimeSeries instance replicates before reverting.

This feature is documented in the IBM Informix Enterprise Replication Guide. See Resources for a link.

Reduce replication latency between Enterprise Replication and shared-disk secondary servers

If an Enterprise Replication server is a primary server for shared-disk secondary servers, you can reduce replication latency by reducing the number of transactions that are applied before the logs are flushed to disk. By default, the logs are flushed after 50 transactions are applied or 5 seconds elapse. You can set the CDR_MAX_FLUSH_SIZE configuration parameter to 1 to flush the logs after every transaction and reduce replication latency.

Listing 10. CDR_MAX_FLUSH_SIZE parameter in the ONCONFIG
#
# CDR_MAX_FLUSH_SIZE        The max number of replicated transactions
#                           applied before a log flush is performed.

CDR_MAX_FLUSH_SIZE  50

Conversion impact: This is not really a conversion issue; however, you might want to review the value of CDR_MAX_FLUSH_SIZE after successfully upgrading.

This feature is documented in the IBM Informix Enterprise Replication Guide. See Resources for a link.

Apply transactions for a replicate serially

You can specify to apply replicated transactions for a specific replicate serially. By default, replicated transactions are applied in parallel. If Enterprise Replication detects deadlock conditions, it automatically reduces the parallelism for the replication system until the problem is resolved. If you have a replicate that consistently reduces parallelism or your application requires serial processing, you can define the replicate with the --serial option. By isolating a problematic replicate, you can improve the performance of the rest of the replication system. The onstat -g rvc full command displays the number of concurrent transactions and whether any replicate is preventing parallel processing.

Reversion impact: You must delete the replicate that was defined using this feature before reverting.

This feature is documented in the IBM Informix Enterprise Replication Guide. See Resources for a link.

Enterprise Replication must be active to revert to a previous version

Starting with Informix 12.10, Enterprise Replication must be running or you must delete the replication server before you revert to a previous version.

If you stop Enterprise Replication before running the script to perform the reversion, you will get an error.

Listing 11. Error when trying to revert with Enterprise Replication inactive
$ /opt/informix/etc/conv/revcdr.sh 12.10 11.70 
Removing internal replicates 
In order to revert Enterprise Replication to a previous version, Enterprise 
Replication must be active.  Run "cdr start" and retry the revert program.
command failed -- Enterprise Replication not active  (62) 
CDR reversion test failed: for details look in 
/opt/informix/etc/revtestcdr.out

Reversion impact: Enterprise Replication must be running or you must delete the replication server before reverting.

Improved transactional consistency for HDR synchronization

Use improved HDR synchronization options to balance system performance and data protection in your high-availability cluster. Set the new HDR_TXN_SCOPE configuration parameter or environment option to choose between fully synchronous mode, asynchronous mode, or nearly synchronous mode. The three synchronization modes control when transaction commits are returned to client applications: after being processed on the primary server, after being sent to the HDR secondary server, or after being processed on the HDR secondary server. HDR synchronization can be set at the instance or session level.

Listing 12. HDR_TXN_SCOPE parameter in the ONCONFIG
# HDR_TXN_SCOPE     - Defines transactional synchronization in the
#                     HDR primary when DRINTERVAL is turned off
#                     The default is NEAR_SYNC.
#                     Valid values are
#                     ASYNC       - Commits are not synced
#                     NEAR_SYNC   - The committed transaction has been
#                                   sent to the HDR secondary but not yet
#                                   applied.
#                     FULL_SYNC   - The transaction has been sent and
#                                   applied on the HDR secondary.

HDR_TXN_SCOPE           NEAR_SYNC

Conversion impact: This is not really a conversion issue; however, you might want to review the value of HDR_TXN_SCOPE after successfully upgrading.

This feature is documented in the IBM Informix Administrator's Guide and the IBM Informix Administrator's Reference. See Resources for a link.

Compatibility of Connection Manager with Informix 12.10

IBM Informix Connection Manager with version 3.70.xC4 or older might not work with Informix 12.10. You can install a new Connection Manager with either IBM Informix Client SDK or IBM Informix Connect.

Either upgrade to the corresponding new version of Client SDK or Informix Connect or install Client SDK or Informix Connect in a different directory from your existing instance and use the Connection Manager from that directory.

Conversion impact: You must upgrade the Connection Manager first, before upgrading the database server to Informix 12.10.

SMX Activity Wait Time

You can set the SMX_PING_INTERVAL and SMX_PING_RETRY configuration parameters to adjust the interval that a secondary server in a high-availability cluster waits for activity from the primary server.

If the secondary server does not receive any message during the length of time that is specified by the SMX_PING_INTERVAL configuration parameter and after the number of intervals that are specified by the SMX_PING_RETRY configuration parameter, the secondary server prints an error message to the online.log file and closes the SMX connection.

Listing 13. New SMX parameters in the ONCONFIG
# SMX_PING_INTERVAL   - Specifies the maximum number of seconds to wait before
#                       closing a network connection to an unresponsive
#                       peer server.
#                       Acceptable values are:
#                       0   Connections are not closed
#                       1-60 Number of seconds to wait
# SMX_PING_RETRY      - Specifies the number of times to repeat
#                       SMX_PING_INTERVAL before closing a connection.
#                       Can be any positive numeric value.

SMX_PING_INTERVAL       10
SMX_PING_RETRY          6

Conversion impact: This is not really a conversion issue; however, you might want to review the values of SMX_PING_INTERVAL and SMX_PING_RETRY after successfully upgrading.


Conclusion

This article has provided all the necessary information about the migration paths to Informix 12.10, the Conversion Guard, the new SQL keywords, the removed features or products, and an overview of new and enhanced features, so you should be able now to plan a successful and smooth upgrade to Informix 12.10.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Information management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management
ArticleID=873031
ArticleTitle=Upgrading to Informix 12.10
publish-date=04252013