Version: 7.31.UD8
PROPRIETARY DATA
THIS DOCUMENT CONTAINS TRADE SECRET DATA WHICH IS THE PROPERTY OF IBM Corporation. THIS DOCUMENT IS SUBMITTED TO RECIPIENT IN CONFIDENCE. INFORMATION CONTAINED HEREIN MAY NOT BE USED, COPIED OR DISCLOSED IN WHOLE OR IN PART EXCEPT AS PERMITTED BY WRITTEN AGREEMENT SIGNED BY AN OFFICER OF IBM SOFTWARE, INC. THIS MATERIAL IS ALSO COPYRIGHTED AS AN UNPUBLISHED WORK UNDER SECTIONS 104 AND 408 OF TITLE 17 OF THE UNITED STATES CODE. UNAUTHORIZED USE, COPYING OR OTHER REPRODUCTION IS PROHIBITED BY LAW.
This product includes cryptographic software written by Eric Young (eay@mincom.oz.au). IT IS PROVIDED BY ERIC YOUNG "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Description: release notes file (without fixed bugs) for database server product.
Owner group: Information Development
*****************************************************************************
IMPORTANT:
The
name of the database server has been changed from "Informix Dynamic Server"
to "IBM Informix Dynamic Server." Please note that products and documentation
that include the word "Informix" are now "IBM Informix." Except for pathnames,
configuration parameters, environment variables. and user informix, the
"IBM" should be prefixed for any reference to "Informix" in any context
of the product, documentation, and other "Informix" items.
A. Interim
Requests
B.
7-family Specific Bugs
C.
Online Help Enhancements
D. Support
for 64bit onperf
E. Onbar
permission changes
F. Onbar
cold restore procedure changes
G. onstat
option documentation for NT/Windows 2000
H. Server
Utilities Check for Secure Environment Before Starting on UNIX
Some bug fixes for which there was only a 7-based solution were included.
Online help for onperf and ipload has been enhanced to display help information with a web browser. Utilization of the new help system requires the use of the new environment variable INFORMIXBROWSER. The user of the onperf or ipload tool must set the INFORMIXBROWSER variable to an existing path and executable name of a web browser prior to execution of the tool. When help is requested from within the tool, a web browser will be opened displaying the requested information in html format.
A 64-bit version of onperf was added to the distribution and will be supported for 7.31.UD6 and later releases on AIX, Solaris, and HP.
A 64-bit version of onperf is now available
The ON-Bar program should now be executed by user 'informix' instead of user 'root'. Users who belong to the group 'informix' or the group 'bargroup' are also allowed to run ON-Bar.
F. Onbar cold restore procedure changes
Disable rootdbs mirroring before
you perform a cold external restore of the rootdbs.
1. In the ONCONFIG file, set MIRROR to 0, unset MIRRORPATH and MIRROROFFSET.
2. Restart the database server for the ONCONFIG changes to take effect.
The rootdbs is no longer mirrored.
3. Move the oncfg file to another location to prevent the database server from
reading the mirroring information from this file.
4. Perform the cold restore as described in "Cold External Restore Procedure"
on page 13.
5. Use the following command to enable mirroring of the rootds: onutil ALTER
DBSPACE rootdbs START MIRRORING CHUNK "pathname" MIRROR "pathname"
6. If you need to bring the database server back to the way it was before the
restore, move the oncfg file back to its original location.
G. onstat option documentation for NT/Windows 2000
The onstat options '-g glo' and '-g sch' on Windows 2000/NT will not show process id as the virtual processors are OS threads actually. The values displayed under the field 'pid' are actually the OS thread ids and not process ids.
H. Server Utilities Check for Secure Environment Before Starting on UNIX
IBM recommends that you follow the installation instructions to ensure the permissions of all key files and directories are set appropriately. To provide increased security, key server utilities now check to determine if your environment is secure. Before the server will start, the following settings must be unchanged from the settings established during installation:
If the tests for any of these conditions fail, the utilities exit with an error message.
a. Disabling Security Checking
Although IBM strongly recommends against doing so, you can partially disable
the security checking for Dynamic Server residing in a specific $INFORMIXDIR
directory. To disable security checking, as the user root, run the INFORMIXDIR/etc/informixdir-is-insecure
script. After this script is run successfully, the warning messages still appear
when the utilities are run, but the programs continue.
NOTE: You may specify the value of INFORMIXDIR on the command line as an argument to the script. Thus, you do not have to set INFORMIXDIR in the root user environment.
The informixdir-is-insecure script creates a /etc/informix directory (if necessary) that is owned by root and has 555 permissions. In this directory, the script creates a file named server-7.31.UD7 that has 444 permissions. This file lists the $INFORMIXDIR values for which security checking is disabled.
NOTE: The format of the contents of the server-7.xx.yyy files might change in future releases.
When you upgrade Dynamic Server, you must rerun the informixdir-is-insecure script to disable security checking because the file name in /etc/informix is different for each version. You may remove old files once the server in question is no longer installed on your machine.
If you choose to disable the security checking, you are very strongly encouraged to use the ibmifmx_security.sh script to limit the number of SUID and SGID programs on your system.
b. Securing an Insecure Environment
If Dynamic Server reports that your
environment is no longer secure and the programs exit, user root can
reset the relevant directory permissions so that they are secure again by running
the $INFORMIXDIR/etc/make-informixdir-secure script. Although user informix
is also permitted to run the script, it cannot fix the problems unless the directory
is owned by user informix. However, the error messages will indicate
what needs to be fixed still. The script also reports on files and directories
under $INFORMIXDIR which belong to an unexpected owner or group, or which have
public write permission.
c. Warning
and Error Messages for Utility Security Checks
If the security check a server utility performs at startup detects a problem,
it will return an error message. These messages are returned when the message
file and internationalization support are not available; therefore, they do
not have error numbers and are not translated.
For the following problems, one of the following messages will display and the utility will continue.
ONCONFIG not set; TBCONFIG set. TBCONFIG will not be supported in future.
For the following problems, the utility exits and displays one of the following messages.
This table defines the variables used in the messages above.
| filename | a name of the file or directory |
| logical-file | either ONCONFIG, INFORMIXSQLHOSTS, INFORMIXDIR, or INFORMIXDIR/xxx
(where xxx is one of a number of sub-directories under $INFORMIXDIR). For example, if INFORMIXDIR is set to /usr/informix, the message might read: INFORMIXSQLHOSTS /usr/informix/etc/sqlhosts is not owned by the user with id 1234. |
| mode | an octal permissions value |
| UID | a number |
| GID | a number |
|
informix |
informix |
755 |
|
|
informix |
informix |
755 |
|
|
informix |
informix |
755 |
|
|
informix |
informix |
755 |
|
|
informix |
informix |
755 |
|
|
informix |
DBSA |
775 |
|
|
informix |
AAO |
770 |
|
|
informix |
DBSSO |
770 |
The following Dynamic Server utilities are SGID informix:
A. B-TREE SCANNER
===================
The new B-tree scanner improves transaction
processing for logged databases when rows are deleted from a table with indexes.
The B-tree scanner threads remove deleted index entries and rebalance the index
nodes. The B-tree scanner automatically determines which index items are to
be deleted, based on a priority list.
1. Controlling the B-tree Scanner
-----------------------------------------------
Use the onmode -C command to control the B-tree scanner for cleaning indexes
of deleted items. There is no limit to the number of threads that can run at
one time. However, only 128 threads that can be started at one time.
If, for
example, you wanted 150 threads
to run, you could execute two
commands: onmode -C 100 and onmode -C 50. The following options are available
with the onmode -C command:
The B-tree scanner assigns a profile
to each index, depending on the amount
of extra work the index places on the server. From the index profiles, the
B-tree scanner develops a hot list: btc_create_hot_list. The B-tree scanner
keeps track of the number of times items in an index causes the server to do
extra work and cleans that index first. The index causing the next highest
amount of extra work will then be cleaned, and so on in descending order.
The B-tree scanner allocates cleaning threads dynamically, which allows for
configurable workloads.
2. Printing B-tree Scanner Information
------------------------------------------------------
Use the onstat -C command to print the file information about the B-tree
scanner subsystem and each B-tree scanner thread. The following options are
available with the onstat -C command:
This release of IBM Informix Dynamic Server includes the most important of the changes recommended by the Tech Alert, but you can improve the security of your system still more by reading the Tech Alert to understand the issue and by using the script, ibmifmx_security.sh. The script is located in the directory /vobs/tristarm/sqldist/bin. Information on how to use the script, ibmifmx_security.sh, has been placed in the "README" section present at the top of the script.
You should also take care to ensure that the following security precautions are implemented:
Also, remember to follow these basic security rules for IBM Informix software:
The following sections describe issues and restrictions that can affect various features of Version 7.31.UD6.
G. Client Connections During Server Recovery with Enterprise Replication
INSERT INTO <target-table>
(SELECT * FROM <source-table> WHERE ...);
The earlier implementation did not allow the source table to be the same as the target table. Any table occurrence in the SELECT clause of the INSERT clause cannot have the target table. The server returns error -360 if it detects such a case.
This feature relaxes the above restriction by allowing the use of target tables in the SELECT clause of the INSERT statement.
The effect of the above statement is the same as the following statements executed in a transaction.
SELECT * FROM <source-table> WHERE ... INTO TEMP<temp-tab>;
INSERT INTO <target-table> SELECT * FROM<temp-tab>;
DROP TABLE<temp-tab>;
If procedure <someproc> scans or updates<target-table>, then the database server returns error -360.
The behavior of the UPDATE and DELETE statements has not changed where the target table is used in their select subqueries. In this case, the database server returns error -360.
The stdev() function has changed from calculating 'sample deviation' to calculating 'population deviation.' The difference between the two is in the final divide by the value '/N' in the expression. For sample deviation, we would divide by 'N-1' and for population deviation, which we are now calculating, we use 'N'. Users will find that our calculation of the standard deviation is different from earlier server versions, the difference being (N-1)/N and, of course, the special case when N is 1.
Use the following formula to calculate the population deviation:
(sum((X[k])^2) - (sum(X[k]))^2/N) / N
By definition, the population deviation for a population of 1 is 0. If you wish, you can omit such cases through the appropriate query construction; for example, "having count(*) > 1."
fragmentation expressions, stored procedures, triggers, check constraints, and user defined routines.
Note that not all of these features may be supported on this version of the product.
The release of IBM Informix Dynamic Server 7.31.UD1 introduces a change in when date literals with two digit years within expressions of objects are evaluated according to the settings of relevant environment variables, such as, and not limited to, DBCENTURY. Previous to this release, two digit year dates in the expressions of the objects were interpreted by IBM Informix Dynamic Server according to the environment variable settings which prevailed at runtime time of the object. However, starting with this release, the date literal will always be interpreted using the environment variable settings prevailing at the creation time or the time of last modification of the object with which the date literal is associated. The settings of environment variable at runtime of the object will not be used.
This applies only to date strings having two digit years in the expression of the objects mentioned above; i.e. it does not apply if four digit years are used in the objects.
The following two steps are required to take advantage of this change introduced in this software:
1. Upgrade IBM Informix Dynamic Server to this release
2. Redefine all objects that use two digit year expressions.
For fragmentation expression, redefining means detaching and reattaching
the expression. For all other objects, the object must be dropped
from the database and recreated.
Only after the objects are redefined using this new server, the date literals in the expressions within objects will be interpreted according to the environment variable settings at the time the object was created or last modified. The reference date used for this interpretation is the creation date or the last modification date of the object and not the current date when a query is run.
If the objects are not redefined using this new server, the behavior of the object will remain the same as prior to the upgrade. However, since any new objects created after the software upgrade will behave differently from those created prior to the upgrade, administration of the database may become difficult because the database will have a mix and match of new and old behavior of objects in the database (with respect to when a two digit years within expressions of objects are evaluated). Therefore, it is recommended that the two upgrade steps above be followed.
Lastly, in order to avoid any possibility of misinterpreting two digit years within the objects, it is recommended that this opportunity be used to change the use of two digit years to four digit years instead, if possible.
In the rare case that the setting of DBDATE prevailing at creation time or time of last modification of the object differs from the one that is in effect at the run time of the object, you may either get a runtime error from the server or get erroneous results due to incorrect interpretation of the date literal.
In order to maintain consistency, starting with objects created or modified using this release, the date literals within expressions of objects will be evaluated according to the setting of DBDATE prevailing at creation time or time of last modification of the object. The settings of environment variable at runtime of the object will not be used to evaluate the date literal within the objects. However, the prevailing setting at runtime of the query will still be in effect for date related data processed within the query.
If your operating environment is such that the objects were created using one set of assumptions regarding the DBDATE setting and the runtime environment uses a different setting, you may encounter some problems. It is recommended that the usage of the database be modified so that the settings of DBDATE at creation, modification, and run time are consistent throughout.
The new behaviour is :
IF PDQPRIORITY environment variable is set in user(onpload) environment
THEN
let server use it to do unload
ELSE
IF it was set in the engine startup environment
THEN
let server use it do unload
ELSE
let server use value of 100 to do unload.
Note : HPL will not allow unloading to multiple devices if PDQPRIORITY is zero or when the PDQ is turned off at the server side either by setting MAX_PDQPRIORITY to zero in ONCONFIG or through 'onmode -D' command. In such cases an error message will be added to the onpload log file.
"Cannot unload to multiple devices with PDQ turned off, either at client or server side."
For more information on PDQPRIORITY environment variable, see the IBM Informix Guide to SQL: Reference.
If continuous logical backup is disabled using ALARMPROGRAM, then manual backup must be performed whenever logical log files get full.
See Administrator's Guide for IBM Informix Dynamic Server and Backup and Restore Guide for IBM Informix Dynamic Server for its usage and details.
F.
Committing In an ANSI Database in Non-Interactive Mode
In ANSI database, if there are no errors and there are no CLOSE DATABASE, COMMIT WORK, or DISCONNECT statements, the database server commits when exiting from Dbaccess in non-interactive mode.
You must issue an explicit COMMIT WORK statment to mark the end of each transaction. Otherwise, the database server commits when exiting from DB-Access in non-interactive mode, as long as there are no errors.The DISCONNECT statement generates an error during a transaction. The transaction remains active, and the application must explicitly commit it or roll it back. If an application terminates without issuing DISCONNECT (because of a system failure or program error, for example), and if there are no errors encountered while exiting from DB-Access in non-interactive mode, the database server commits.
G. Client Connections During Server Recovery with Enterprise Replication
While recovering the IBM Informix Dynamic Server instance, if Enterprise Replication is active, then client (sqlexec type) connections are allowed only after Enterprise Replication recovery is completed. This is true even while changing the server mode from quiescent mode to online mode.
DB/Cockpit
Starting with the release of IDS Version
7.31.UD4 the Utility DB/Cockpit is no longer supported. The functionality
provided through this utility can be obtained using ISA.
TBCONFIG environment variable
This environment variable is replaced
by the ONCONFIG environment variable. If you continue to use TBCONFIG
instead of ONCONFIG, you will receive a warning. In a future major release,
the TBCONFIG environment variable may no longer be supported.
1. Stop all IBM Informix services, including:
- IBM Informix database server
- IECC (if installed)
- IBM Informix Storage Manager (ISM)
2. Uninstall old client products.
3. Uninstall the 7.30 database server. Choose the option "remove only database
server executables and support files."
4. Install the 7.31 database server.
5. Install IBM Informix DB Administrator (includes ISM GUI, Enterprise
ERM, Client Configuration, and Schema tools).
6. Install Client SDK 2.24 or greater.
7. Reboot the computer.
8. Set the environment variables through setnet32.
The new IDS 7.31 database server should now be accessible.
To convert or revert existing data, use the following guidelines:
*Data integrity
check
oncheck
*Level-0 backup
*Server shutdown
onmode
-yuk
---------------------
Target
---------------------
Server
startup
oninit
*Update statistics
highly recommended
*Data integrity
check
oncheck options
*Level-0 backup
*Single
User Mode
onmode -sy
onmode -l
onmode -c
*Data
integrity check
oncheck
*Level-0 backup
*Activate
reversion and shut down server
* onmode
-b version
------------------------------
Target
-----------------------------
Server
startup
oninit
*Update statistics
recommended
*Data integrity
check
oncheck
*Level-0 backup
During the conversion or reversion process, monitor the server online.log activity.
* To find what version to use when you revert from 7.3 to a previous version, use onmode -b --.
Before shutting down the old database server, alter all RAW tables to STANDARD. Later, if you convert from the older version to 7.31, these tables remain STANDARD.
If RAW tables were updated since the last backup, you must perform a level-0 backup.
Migrating and Reverting with Enterprise Replication (See also workaround for PTS Bug 153432 in the file fixed_and_known_defects_731.html)
For important migration information about the following topics in the Migration Guide documentation notes:
o Migrating
the syscdr database
o Modifying
SQL statements larger than 255 bytes
o Retaining
Enterprise Replication state during migration
o Reverting
to 7.20 which does not support Enterprise Replication
All the conversion and reversion operations must be performed by user 'informix'.
1. Before shutting down the old database server
a) Stop applications doing replicatable transactions.
b) Make sure that control and TRG send queues are empty.
Run 'onstat -g grp' to ensure grouper doesn't have any pending transactions.
Sample Output:
IBM Informix Dynamic Server Version 7.31.UC1--On-Line--Up
00:28:15--18752 Kbytes
Grouper:
Last Idle Time: 98/11/09 15:12:01
Log update buffers: 1024
Log update buffers in use: 0
Log update buffers in use should be zero.
Run 'onstat -g rqm' to check for queued messages.
Sample Output:
RQM Statistics for Queue #3
Database name:
syscdr
Table name:
control_sendq
Index name:
control_sendq_key
Flags:
0x00000301
Elements in memory:
0
Elements on disk only: 0
Memory used for data:
0 Bytes
Total memory used:
0 Bytes
Element high water mark: 2000
Data high water mark:
140000 Bytes
Elements stored on disk: 0
'Elements in memory' and 'Elements stored on disk' should be zero.
c) Make sure that CDR is in stopped state or use the stop_cdr program in the demo directory. In 7.30 and 7.31, you can execute 'cdr stop' command to stop CDR. In 7.2x servers, you have to use Enterprise ERM for this.
2. Shut down the old server and bring up 7.31 server on the same root dbspace.
3. Take a full backup of syscdr and databases.
4. Make sure that no replicatable transactions occur in the system before CDR is started.
5. If you are converting from release 7.30, rebuild sysmaster database using the "buildsmi" command.
6. Run the concdr script that is in the /vobs/tristarm/sqldist/etc directory.
% concdr <fromvers> 7.31
Valid values for <<from vers> are "7.2" or "7.3." Wait for the message:
'syscdr' conversion completed successfully.
or
'syscdr' conversion failed.
For details, look in /vobs/tristarm/sqldist/etc/concdr.out.
7. If conversion failed, then resolve the problem reported in /vobs/tristarm/sqldist/etc/concdr.out. Restore the 'syscdr' database from backup and then attempt conversion again.
8. Bring up CDR after successful conversion.
% cdr start
1. Stop applications doing replicatable transactions.
2. Make sure that the control and TRG send queues are empty.
Run 'onstat -g grp' to check for pending transaction in the grouper.
Sample Output:
IBM Informix Dynamic Server Version 7.31--On-Line--Up
00:44:30--18968 Kbytes
Grouper:
Last Idle Time: 98/11/09 15:01:15
Log update buffers: 1024
Log update buffers in use: 0
Log update buffers in use should be zero.
Run 'onstat -g rqm' to find out the elements in the queue.
In the output look for 'Txns in queue: 0' for both
'control_send' and 'trg_send' queues.
Sample output:
RQM Statistics for Queue (0xa6c4018) trg_send
Transaction Spool Name: trg_send_stxn
Insert Stamp: 0/0
Flags: SEND_Q, SPOOLED, PROGRESS_TABLE, NEED_ACK
Txns in queue:
0
3. Shut down cdr using 'cdr stop' command.
4. Take a full backup of the 'syscdr' database.
5. Run the reversion test script to make sure that none of the new features are being used.
% revtestcdr 7.31 <to version>
Valid values for <<to versions> are "7.3" and "7.2"
6. If the reversion test succeeds, then run the actual reversion.
% revcdr 7.31 <to version>
7. If the reversion fails then check the file /vobs/tristarm/sqldist/etc/revcdr.out. Attempt reversion after resolving problems reported in revcdr.out and restoring syscdr from backup.
8. If you are reverting to 7.2x, then to revert the rest of the server, run the following command:
% onmode -b 7.2
Note: This will automatically bring down the database server.
If the reversion is to 7.30, then you need to shut down the database server manually.
9. Bring up old database server.
10. If you are reverting to release 7.30, rebuild sysmaster database using the "buildsmi" command.
11. To bring up Enterprise Replication
after a successful reversion, use the "cdr start" command for 7.30 or use
the or use the Enterprise ERM for 7.2x.
For more information about reverting from IBM Informix
Dynamic Server Version 7.31 to an older database server, see the IBM
Informix Migration Guide.