Webcast: Top 10 reasons to consider IBM Data Server Driver for JDBC and SQLJ for IDS servers

• Date: Wednesday, Feb the 24th
• Time: 1.5 hour, 8:30 AM Pacific, 10:30 AM Central, 11:30 AM Eastern, 4:30 PM London, 5:30 PM Berlin/Paris
• Title: Top 10 reasons to consider IBM Data Server Driver for JDBC and SQLJ for IDS servers
• Speaker: Satheesh Bandaram (IBM)

You can register for the webcast here...

Reminder: HDR Webcast

• Date: Wednesday, Jan the 20th
• Time: 1.5 hour, 8:30 AM Pacific, 10:30 AM Central, 11:30 AM Eastern, 4:30 PM London, 5:30 PM Berlin/Paris
• Title: HDR Best Practices and Performance Tuning
• Speaker: Ronald Privett (IBM)

You can register for the webcast here...

• Date: Thursday, Nov the 18th
• Time: 1.5 hour, 8:30 AM Pacific, 10:30 AM Central, 11:30 AM Eastern, 4:30 PM London, 5:30 PM Paris
• Title: MACH11 best practices around HDR/RSS
• Speaker: Madhuri, Madison Pruet (IBM)

You can register for the webcast here...

Jerry Keesee, Director of the Informix Lab will introduce the call 
and Madison Pruet, Informix STSM will be our technical speaker.

• Description
• Usage
• Output
• Example 24 Hour Range
• Example 6 Hour Range
• Example 1 Hour Range
• Download

Description

Did you ever ask yourself one or more of the following questions:

MACH11: TEMPTAB_NOLOG

In IDS V11.1 there has been a new onconfig parameter introduced: TEMPTAB_NOLOG

The purpose of this parameter is:

• Allowing the creation of unlogged temporary tables on secondary servers (SDS,HDR,RSS) without the need to explicitly add the with no log extension
• Increasing performance for operations on temporary tables on the primary (PRI) as statements against them will not be logged and hence not transfered to a secondary server

Let's have a deeper look at this technique. In the following example we have a primary server and a secondary HDR server. I leave SDS and RSS secondary servers out, as they show exactly the same behaviour as a HDR secondary regarding the TEMPTAB_NOLOG parameter. The dbspace layout looks like this:

MACH11: HA_ALIAS

In IDS V11.5 there is a new onconfig parameter: HA_ALIAS

HA_ALIAS specifies the IDS servername that a SDS- or RSS-Node will send to the PRIMARY when it registers itself in a MACH-Cluster. The specified HA_ALIAS name must be one of the configured DBSERVERNAME or DBSERVERALIASES servernames that belongs to a TCP based connection type. It will be used in case of failover. If HA_ALIAS isn't set, the value of the DBSERVERNAME acts as the default and will be send to the PRIMARY.

HA_ALIAS is particulary useful in configurations where the DBSERVERNAME onconfig parameter is based on a local connection protocol like onipcshm (shared memory) or onipcstr (stream pipe). In order for such instances to be able to participate as a secondary SDS- or RSS-Node in a MACH-Cluster, HA_ALIAS must be set to a configured DBSERVERALIASES name that belongs to a TCP based connection type.

MACH11: FAILOVER_CALLBACK

In IDS V11.5 there is a new onconfig parameter: FAILOVER_CALLBACK

It is allows you to customize the automatic failover capability of the Connection Manager in some way. FAILOVER_CALLBACK should be set to the full path of your own script. IDS will execute the specified script on a secondary server when:

• the secondary server is promoted to a primary server
• the secondary server is promoted to a standard server

This means that FAILOVER_CALLBACK can be used in conjunction with HDR (DRAUTO) as well as with the Connection Manager FOC (FailOver Configuration) capability.

HDR Parameters and their Meaning

DRTIMEOUT

DRTIMEOUT specifies the upper limit of time that the Primary will wait for an acknowledgment from the Secondary until it assumes a data replication failure. Checkpoints on the Secondary must not exceed the DRTIMEOUT boundary. Primary and Secondary will also ping each other regardless if logical log records are send. DRTIMEOUT specifies the interval at which those pings are send. A HDR failure is assumed after four sequential ping attempts failed. So the DRTIMEOUT parameter should be set to 1/4 (25 %) of the total time that is appropriate before declaring a failure.

Starting HDR and using only level-0 backup vs (currently not implemented) using level-0 with incremental backups

For physical restore secondary of HDR, level-0 must be using. If you are using incremental backups from primary for physical restore on secondary, you get the error on secondary IDS in online.log:

...
11:55:36 DR: new type = secondary, primary server name = hdr_lo
11:55:36 DR: Trying to connect to primary server = hdr_lo
11:55:38 DR: Secondary server restored from a non level-0 archive - aborting
11:55:39 IBM Informix Dynamic Server Stopped.
...

Why IBM does not fix this behavior for possibility using incremental backups for physical restore secondary HDR?