Informix xC5, xC6 & xC7 – New Features

Informix 12.10.xC5, xC6 & xC7 – New Features
Scott Pickett WW Informix Technical Sales For questions about this presentation contact: © 2016 IBM Corporation

Agenda Informix 12.10.xC5 – March 23, 2015
Informix xC6 - November 24, 2015 Informix xC7 – July 23, 2016 Appendicies © 2016 IBM Corporation

Informix 12.10.xC5 – New Features

Agenda Migration Installation Administration Application Development
Time Series Spatiotemporal Warehouse Accelerator Devices Miscellaneous © 2016 IBM Corporation

Agenda - Migration HA Cluster OnLine Rolling Upgrade
AUTO_REPREPARE configuration parameter © 2016 IBM Corporation

HA Cluster OnLine Rolling Upgrade
Rolling upgrades for high-availability clusters Parts of the cluster will always be up to receive data Limited to PID to next PID For example, from xC4 to xC5 NOT 11.7 to 12.1 Major release changes/migrations (V 11.x to V 12.x, for example) usually involve disk and memory changes to sysmaster and system catalogs. Do not use this If you must perform a conversion Release notes … Coming from a special build, for example, xC4W1 to xC5 Unless blessed by Technical Support. You will minimally need 500 MB spare disk space on all servers involved for the install and more if it is Advanced Enterprise/Growth Edition. This is a feature customers using HA Clusters have been requesting for sometime now; the ability to take parts but not all of the cluster down to upgrade it while maintaining business operations. © 2016 IBM Corporation 6

HA Cluster OnLine Rolling Upgrade – Prerequisites (1)
Install the new software on all the servers in the cluster Copy the appropriate configuration files Back up the primary server. Configure client redirection to minimize interruption of service. Set up redirection and connectivity for clients by using the method that works best for your environment. If Connection Manager controls the connection redirection in the cluster: Ensure that every Service Level Agreement (SLA) definition in the Connection Manager configuration file can redirect to at least one server other than the one you are about to update. If you have an SLA with only one secondary: Before you upgrade the secondary server in that SLA, update the SLA to include the cluster primary (PRI). Primary server has an enough disk space for logical log records created during the entire upgrade process. Space required depends on your environment. If a log wrap occurs during the rolling upgrade procedure, you must apply the fix pack or PID while the cluster is offline. © 2016 IBM Corporation

HA Cluster OnLine Rolling Upgrade - Prerequisites (2)
The online log can provide an estimate of your data activity during normal operations. Ensure, minimally, that you have enough space for data activity for a day. Plan the rolling upgrade for a period of low traffic. Prepare the secondary server that will become the primary when you upgrade the original primary server: You must use an SD secondary or a fully synchronous HDR secondary server that has transactional consistency with the original primary server. If the cluster contains an SD secondary server, you don't need to do any additional preparation to that server. If the cluster contains an HDR secondary server, make sure that it runs in fully synchronous (SYNC) mode. If the cluster contains only RS secondary servers in addition to the primary server, you must change one of the RS secondary servers to an HDR secondary server in SYNC mode. © 2016 IBM Corporation 8

Environment Variable Settings
Set the environment to use the fix pack or PID version that you installed on the server. Set INFORMIXDIR to the full path name for the new target installation. Update all variables that depend on INFORMIXDIR PATH DBLANG, INFORMIXSQLHOSTS And any platform-specific library path environment variables, such as LD_LIBRARY_PATH © 2016 IBM Corporation

Server Upgrades in Order of Upgrade
Remote standalone (RS) secondary server HDR secondary server Shared disk (SD) secondary server Primary server Upgrade the primary server only after all the secondary servers are upgraded and tested. After you upgrade the primary server, if you want to revert to your original environment you must take the cluster offline. © 2016 IBM Corporation

Upgrade Steps Per Server (roughly)
onmode -c - to force a checkpoint for each server. If a wire listener is running on the server that you want to upgrade, stop that wire listener: execute function task("stop json listener"); Stop the server that you want to upgrade. If you wait for connections to exit gracefully, onmode -kuy Otherwise, onmode –ky to stop the server. When you stop a secondary server: If redirection is configured for the cluster, the client application automatically connects to another active server in the cluster. When you stop the primary server: If failover is configured for the cluster, a secondary server is promoted automatically to primary. Otherwise: onmode -d make primary - to do the promotion If the primary is offline before the failover - onmode -d make primary force © 2016 IBM Corporation

Rolling Upgrades - Steps to Start
Start the upgraded server. To start an upgraded secondary server: oninit To start an upgraded original primary server: Start the original primary server as a secondary server. For convenience, start it as the server type that was promoted to primary during the rolling upgrade. For example, if you promoted an HDR server to primary for the rolling upgrade, start the original primary as an HDR secondary server. To start the upgraded server as an SD secondary server, oninit -SDS To start the upgraded server as an HDR secondary server, oninit -PHY and then run the following command: onmode -d secondary primary_server secondary_server After the server starts, it runs the new version of the software and automatically reconnects to the cluster. © 2016 IBM Corporation

Return The Upgraded Cluster To Its Original Config
If you want the cluster to operate as before the rolling upgrade: Manually promote the secondary server that was the original primary to be the primary server again. onmode -c - to force a checkpoint. onmode -d make primary - to promote the secondary server to primary. Undo changes that you made when you prepared the servers for a rolling upgrade. Some of these optional steps might not apply to you: Adjust the amount of disk space that is allocated for logical log records. Convert the HDR secondary server back to an RS secondary server. Change the HDR secondary server back to ASYNC mode from SYNC mode. Change the Connection Manager SLA definitions. © 2016 IBM Corporation

Rolling Upgrades – Verification
On both the server you upgraded and on the primary server, verify that the upgraded secondary server is active in the cluster: onstat -g cluster If you stopped the wire listener to upgrade this server, restart the wire listener. © 2016 IBM Corporation

AUTO_REPREPARE Set to (0) to disable or (1) to enable automatic SPL statement re-preparation Default value is not set. Historically, those have been the values allowed: 12.10.xC5 changes this. New values controlling how much and when checking takes place: 3 = Don't check statements successfully executed < 1 sec. ago (optimistic mode) 5 = Check only after update statistics are run 7 = Both 3 and 5 onmode –wm/wf Environment variable: IFX_AUTO_REPREPARE The AUTO_REPREPARE configuration parameter controls whether the database server automatically re-optimizes SPL routines and re-prepares prepared objects after the schema of a table that is referenced by the SPL routine or by the prepared object was changed. Possible values: 0 = Disables the automatic re-preparation of prepared objects after the schema of a directly or an indirectly referenced table is modified. Also disables the automatic re-optimization of SPL routines after the schema of an indirectly referenced table is modified. 1 = Enables automatic re-preparation and automatic re-optimization. 3 = Don't check statements that were successfully executed recently (optimistic mode) 5 = Check only after update statistics are run. 7 = Both 3 and 5 It is possible to improve the speed of queries by controlling when queries are automatically re- prepared, The AUTO_REPREPARE configuration parameter supports these additional values: 3 = Enables automatic re-preparation in optimistic mode. If a statement ran correctly less than one second ago, do not re-prepare the statement. 5 = Enables automatic re-preparation after UPDATE STATISTICS is run. If a statement includes a table on which UPDATE STATISTICS was run, then re-prepare the statement. 7 = Enables automatic re-preparation in optimistic mode and after UPDATE STATISTICS is run. onmode –wm/wf work here. Also works when AUTO_REPREPARE is not set in your current onconfig file and you edit the AUTO_TUNE configuration parameter and restart the database server. If you set the AUTO_TUNE configuration parameter to 1, the database server automatically changes most of the configuration file values that are not set to 1; AUTO_REPREPARE is one of those values. AUTO_REPREPARE is designed to make -710 errors from the database server go away; this error does occur when you have previously modified the schema of a table that a dynamic SQL or DML statement within an SPL (Stored Procedure Language) references. For example, certain DDL statements modify the schema of a table, such as CREATE INDEX, DROP INDEX, DROP COLUMN, and RENAME COLUMN. If the AUTO_REPREPARE configuration parameter is disabled when these DDL statements are run, users might receive errors. These errors occur the next time that you run: An SPL routine that directly or indirectly references tables modified by the DDL statements. A prepared object that references the tables that were modified by the DDL statements. Enabling AUTO_REPREPARE might have no effect on prepared statements or on SPL routines that reference tables in which DDL operations change the number of columns in the table, or change the data type of a column. After these schema changes, you typically must reissue the DESCRIBE statement, for example, to determine the column data type, the PREPARE statement (for prepared objects), and the UPDATE STATISTICS statement (for cursors associated with routines) for optimized SPL routines that reference the table whose schema has been modified. Otherwise, the database server might issue SQL error -710, despite the AUTO_REPREPARE setting. © 2016 IBM Corporation 15

Agenda - Installation Java 7 Support New operating system platforms
Improved logging and debugging Informix server and client products Easier silent installations Deprecated installation options New database server installation guide © 2016 IBM Corporation

Java 7 Support for Informix Dynamic Server
A copy of IBM Runtime Environment, Java Technology Edition, Version 7 is installed on most platforms by default. That version is used to run Java user-defined routines that are created in the server. Henceforth, IBM Informix xC5 software supports Java™ Platform Standard Edition (Java SE), Version 7. © 2016 IBM Corporation

New Operating System Platform Support – 12.10.xC5
Mac OS X 10.8, 10.9 Ubuntu 32-bit for ARM v8 (32-bit) Ubuntu 64-bit for ARM v8 (64-bit) MAC OS X 10.8, 10.9 machine notes. Ubuntu 32 Bit ARM v8 (32 bit) Ubuntu 64 Bit ARM v8 (64 bit) © 2016 IBM Corporation 19

Installer – Installation Logging Improvements
Default name and location of the installation log file for both the database server and client products is now: /tmp/iad_act.log (UNIX, Linux, Mac OS X) \tmp\iad_act.log (Windows). You can specify a different name and location for the installation log file with the -DLOG_FILE option of the installation command. In particular, customers that embed informix as part of their applications and distribute it en masse to customers will find this easing their installation activities. © 2016 IBM Corporation

Installer - Debugging Enhancements
Customers now have more control over the debugging and tracing information for the installation process. By default, tracing is disabled. You can set the tracing level from with the -DDEBUG_LEVEL option in the installation command. If tracing is enabled, the default name and location of the debugging file is /tmp/iad_dbg.log (UNIX, Linux, Mac OS X) \tmp\iad_dbg.log (Windows). You can set the name and location of the debug file with the DDEBUG_FILE option. © 2016 IBM Corporation

Silent Install Enhancements
You can streamline a silent installation on systems with existing database server or client products installations. Include the -DOVERWRITE_PRODUCT=TRUE option with the commands used to install Informix products ids_install installclientsdk installconnect The command will overwrite an existing installation. If FALSE, the installation application exits if it finds a duplicate product installation about to be attempted at the location chosen. © 2016 IBM Corporation

Deprecated Options – Unix/Linux
ids_install, installclientsdk, and installconnect have the following commands options deprecated: -i swing DDEBUG The –i swing option is deprecated; use the -i gui option in the installation command to run the installation application in GUI mode. The -DDEBUG option is deprecated; use the new -DDEBUG_LEVEL option in the installation command to set the tracing level. Business partners and customers whom embed Informix in their apps may be affected in their apps when upgrading. © 2016 IBM Corporation

Agenda - Administration
Multi-tenancy Control tenant resources Sessions Limit session resources Backup and restore Larger maximum tape size for backups © 2016 IBM Corporation

Multi Tenancy – Defined
Tenancy refers to the ability of an Informix server to support a set of users in a client organization needing to access the same data and system resources while denying non-administrative users on the same server from accessing those same resources without permission. Multi tenancy is multiple organizations supported on the same server needing to access only their own segregated data and resources while denying other users access to their data and resources. In tenancy, a dedicated database is created and assigned storage and processing resources for that database based on defined service-level agreements with the client organization. It is possible to have services for multiple companies (tenants) that run efficiently within a single Informix instance. © 2016 IBM Corporation

Multi Tenancy - Session Level Resource Limitations
Session Level Resource Control Limits To improve performance and restrict the tenant database size. Prevents any session owned by non-administrative users from using so many resources that other sessions cannot continue processing transactions. To prevent performance issues. Tenant properties in the tenant definition created when you run the admin() or task() SQL administration command with the tenant create or tenant update arguments. Tenant properties have precedence over related configuration parameters. © 2016 IBM Corporation

Multi Tenancy - Session Level Resource Limitations By
Memory size threshold: Set the session_limit_memory to terminate sessions exceeding a specified maximum amount of session shared memory . Temp space use size threshold: Set the session_limit_tempspace to the maximum amount of session usable temporary storage. Transaction log space size threshold: Set the session_limit_logsize to the maximum size of a session transaction. Transaction is rolled back if the log size threshold is reached. Transaction time property: Set the session_limit_txn_time to the maximum number of seconds that a transaction can run. © 2016 IBM Corporation

Ceiling Caps on Tenant Permanent Storage
You can limit the total amount of permanent storage space for a tenant database by setting the tenant_limit_space property. © 2016 IBM Corporation

Tenant Private Memory Caches
You can now improve processing performance by creating private memory caches for all tenant virtual processors. Set the VP_MEMORY_CACHE_KB configuration parameter to a nonzero value to create private memory caches for all CPU and tenant virtual processors. © 2016 IBM Corporation

User Session Resources Limited (1) (non-tenant)
At a session level, resources can be limited that are owned by non-administrative users to prevent performance issues. This ability can: Prevent any session from using so many resources that other sessions cannot continue processing transactions. Be useful in embedded environments. DBA can specify limiting sessions exceeding a specified amount of shared memory or temporary storage space by setting the following configuration parameters: SESSION_LIMIT_MEMORY to a maximum amount of session shared memory. SESSION_LIMIT_TEMPSPACE to a maximum amount of session temporary storage space. © 2016 IBM Corporation

User Session Resources Limited (2) (non-tenant)
DBA can specify rolling back transactions that are too large or take too long by setting the following configuration parameters: SESSION_LIMIT_LOGSIZE to the maximum amount of log space that a transaction can fill. SESSION_LIMIT_TXN_TIME to the maximum number of seconds that a transaction can run. © 2016 IBM Corporation

Backup and Restore – Zetabytes Size Enhancement
Maximum value of the ontape TAPEDEV and LTAPEDEV configuration parameters is now 9,223,372,036,854,775,807 KB, or 9 ZB. Lack of resources prevented testing this number …………….. Volunteers anyone?  Setting applies to ontape only. onmode –wm/wf work here. © 2016 IBM Corporation

Agenda – Application Development
JDBC Driver Additional locale for the JDBC Driver Correlated aggregate expressions Improved processing within a subquery © 2016 IBM Corporation

Correlated Aggregate Expressions
In a subquery, an aggregate expression with a column operand declared in a parent query block is called a correlated aggregate. The column operand itself is called a correlated column reference. If a subquery contains both a correlated aggregate and a correlated column reference, the database server now evaluates that aggregate in the parent query block where the correlated column reference was declared. If the aggregate contains multiple correlated column references, then the aggregate is processed in the parent query block (where the correlated column reference originated) that is the nearest parent to the subquery. This has lead to improved query processing in queries with these structures and circumstances. © 2016 IBM Corporation

Agenda – Time Series Loading data
Load pure JSON documents into time series Faster loading of time series data files Improved logging for the time series loader Create new time series while loading data Displaying information about time series Display time series storage space usage View active time series loader sessions Querying data Analyze time series data for matches to patterns Clip selected columns of time series data © 2016 IBM Corporation

JSON compatibility Load JSON based document data directly into time series. It was possible to do this previously, except that an extra step was involved where primary key values and timestamps has to be provided in plain text format. Run the new TSL_PutJson() function to load pure JSON documents, either from a file or from a named pipe. Functionality can be used to load JSON documents generated by wireless sensor devices without preprocessing the data. © 2016 IBM Corporation

TSL_PutJson function TSL_PutJson loads JSON documents as time series data. TSL_PutJson( handle LVARCHAR, pathname LVARCHAR ) returns integer handle A table/column name combination returned by TSL_Attach() or TSL_Init(). pathname The fully qualified path and name of a file, which is preceded by the DISK: keyword, or a pipe, which is preceded by the PIPE: keyword. Both keywords must be uppercase. © 2016 IBM Corporation

TSL_PutJson – Rules and Operations (1)
Database server does not verify that: Any file or pipe exists at the specified path The specified pipe is open The user has permission to access that file system. The file contents or input stream must be a set of JSON documents that each represent a time series element. Each document must be on a separate line. Each line must end with a newline character (\n). The entire JSON document is inserted into the BSON column in the TimeSeries data type. © 2016 IBM Corporation

TSL_PutJson() – Rules and Operations (2)
The primary key and time stamp values are also extracted from the JSON documents: Primary key First JSON document must contain one or more field value-pairs comprising the primary key. Field names must match the column names for the primary key in the time series table. If primary key values are not included in subsequent JSON documents, the last primary key value from previous documents is used. Primary key value determines into which time series the JSON document is inserted. Time stamp The field name of the time stamp value must match the column name for the time stamp in the TimeSeries data type. Time Stamp format is specified by the timestamp_format argument of TSL_Init(). Time Stamp default format is: YYYY-mm-dd HH:MM:SS (year-month-day hour:minute:seconds). © 2016 IBM Corporation

TSL_PutJson() – Usage Use TSL_PutJson() to load time series data that is in JSON documents as part of a loader program: Within the context of a loader session initialized by TSL_Init() Can be run multiple times in the same session. Data stored in the database server until TSL_Flush() runs to write the data to disk. Primary key value and the time stamp are extracted from the JSON documents and inserted into the corresponding columns in the TimeSeries data type. They also remain in the original JSON documents stored in the BSON column of the TimeSeries data type. Reject records are listed in the reject file, reject_file.log, that is specified by the TSL_init(), and the reject_file.log.ext file that is in the same directory as the reject log. © 2016 IBM Corporation

TSL_PutJson() – Return Data & Examples
Returns An integer that indicates the number of records that were inserted. An exception if no records were inserted. The examples below run within the context of an initialized loader session. Example 1: Load from a file into a time series EXECUTE FUNCTION TSL_PutJson('tsdata|pkcol', DISK:/mydata/loadfile.unl'); Example 2: Load from a pipe into a time series EXECUTE FUNCTION TSL_PutJson('tsdata|pkcol', 'PIPE:/usr/local/TAPE'); © 2016 IBM Corporation

Faster Time Series Data Loads – TSL_Put() Function
Load files directly into the database by specifying a file path as the second argument to TSL_Put(). Values can be JSON Documents or in BSON format. Previously, the TSL_Put() accepted data as only LVARCHAR or CLOB data types, which require intermediate steps to process the data: If you included the data as a string, the client processes the string into an LVARCHAR data type. Now, if you include the data file as a CLOB, the server loads the contents of the file into a CLOB data type and then reads the data from that CLOB data type. The time series data that you load with TSL_Put() can now contain JSON or BSON documents as values for columns other than the primary key and timestamp columns. EXECUTE FUNCTION TSL_Put('tsdata|pkcol','file:/mydata/loadfile.unl'); © 2016 IBM Corporation

Improved Time Series Loader Logging
If you write a loader program to load time series data, you can choose to retrieve loader messages from a queue instead of logging the messages in a message log file. Retrieving messages from a queue results in less locking contention than logging messages in a file. Retrieve queued messages as formatted message text in English by running the new TSL_GetFmtMessage() function. Alternatively, run the TSL_GetLogMessage() function to return message numbers Run the TSL_MessageSet() function to return the corresponding message text. This method is useful if you want to provide your own message text or if you want to retrieve message text on the client. © 2016 IBM Corporation

Create New Time Series While Loading Data
You can now create a new time series instance while loading data with a time series loader program. Previously, you had to insert primary key values and create time series instances before you loaded data with a loader program. For a loader program, you can specify the definition of a time series instance by running the new TSL_SetNewTS() function. You can specify if the time series definition applies to the current loader session or to all loader sessions. When you load data with TSL_Put () for a new primary key value, a new row is added to the table and a new time series instance is created based on the definition. For a virtual table, you can create a new time series instance while quickly inserting elements into containers. © 2016 IBM Corporation

Create New Time Series While Loading Data
In the TSCreateVirtualTab() procedure, set the NewTimeSeries parameter and the elem_insert flag of the TSVTMode parameter. Set the origin automatically of any new time series instance to the day that the time series is created by including formatting directives for the year, month, and day. Formatting directives for the origin in the time series input string can be included within an INSERT statement or in the NewTimeSeries parameter in the TSL_SetNewTS() function and the TSCreateVirtualTab() procedure. © 2016 IBM Corporation

TSL_SetNewTS function (1)
Controls new time series creation via a loader program. Syntax (3 possibilities) TSL_SetNewTS( handle LVARCHAR, NewTimeSeries VARCHAR DEFAULT NULL, per_session INTEGER DEFAULT NULL) returns INTEGER; NewTimeSeries VARCHAR DEFAULT NULL) handle LVARCHAR) © 2016 IBM Corporation

TSL_SetNewTS() function (2)
handle The table and column name combination that is returned by TSL_Attach() NewTimeSeries (optional) Controls insertion of elements into a time series non-existent in the base table: Because the row does not exist or The row does not yet have a time series instance. A time series input sting = new time series definition to create. The threshold parameter must be set to 0. If you use current date formatting directives in the origin parameter, the origin is set to the current date when the time series instance is created. NULL = Default. New time series creation is disabled. per_session (optional) Sets the scope of the NewTimeSeries parameter: 0 = Global. Default. Parameter used in subsequent loading operations in all loader sessions for the specified handle. 1 = Session. Parameter used in subsequent loading operations in the current loader session only for the specified handle. Overrides global setting of the NewTimeSeries parameter. © 2016 IBM Corporation

TSL_SetNewTS() function – Usage (1)
Controls whether a loader program can insert data that requires a new row in the base table, or a new time series in a row that does not have an existing time series instance. By default: Attempting to insert data for a new primary key value or for a TimeSeries column that is NULL, causes the data to be rejected. Must run TSL_SetnewTS() in the context of a loader session that was initialized by the TSL_Init() function. If you set the NewTimeSeries parameter to a time series definition, the following functions can insert data for new time series: TSL_Put() TSL_PutRow() TSL_PutJson() TSL_PutSQL() If the primary key value does not exist in the base table, a new row is added to the base table. The primary key value is inserted and a new time series instance is created with the supplied values. Data is inserted into only the primary key columns and the TimeSeries columns, regardless of whether values for other columns are included in the data. The other columns in the base table are filled with default values, if defaults are defined, or else null values. If any of the other columns has a NOTNULL constraint and no default value defined, the row is rejected. If the row for the primary key value exists but the TimeSeries column is NULL, a new time series instance is created with the supplied values. © 2016 IBM Corporation 52

TSL_SetNewTS() – New Time Series Creation Methods
Enable creation of a new time series: Use TSL_SetNewTS() function with a time series definition in the NewTimeSeries parameter. Change the new time series definition previously set by TSL_SetNewTS(). Run TSL_SetNewTS() with a different time series definition in the NewTimeSeries parameter. Definition can be changed for the current session or globally for all sessions. Disable new time series creation previously set by TSL_SetNewTS(): Run TSL_SetNewTS() without the NewTimeSeries parameter. You can disable new time series for the current session or globally for all sessions. Returns 0 = The new time series creation rule is changed for the specified scope. 1 = An error occurred. © 2016 IBM Corporation 53

Examples Set a global new time series creation definition:
EXECUTE FUNCTION TSL_SetNewTS('iot_device_data|ts_data', 'origin( :00: ), calendar(ts_1min), container(iot_cn2), threshold(0), irregular', 0); Set a new time series definition for a session: 'origin(%Y-%M-%D 00:00: ), calendar(ts_1min), container(iot_cn2), threshold(0), irregular', 1); The origin is set to the day on which the time series is created by inserting data. The first example statement enables new time series creation and sets a definition for new times series for all sessions that update the ts_data column in the iot_device_data table. The second example statement sets a definition for new times series for the current session that updates the ts_data column in the iot_device_data table: © 2016 IBM Corporation 54

Displaying Information About Time Series - Monitoring
Active time series loader sessions: When you run a time series loader program, you open a loader session for each table and TimeSeries column combination into which you load data. You can view a list of handles for active loader sessions by running the TSL_ActiveHandles() function: The handle consists of the table name and the TimeSeries column name. execute function TSL_ActiveHandles() returns SET(LVARCHAR NOT NULL) SELECT * FROM TABLE(tsl_activehandles()) AS t(al) al iot_device_table|ts_data al meter_data|readings TSL_ActiveHandles() returns SET(LVARCHAR NOT NULL) Usage: Run the TSL_ActiveHandles function to get a list of active loader sessions that were initialized by the TSL_Init function. Returns: A SET data type with one or more handles for active loader sessions. Each handle consists of a table name and a TimeSeries column name. or NULL if no loader sessions are active. Example The following statement returns the handles for active loader sessions: EXECUTE FUNCTION TSL_ActiveHandles(); SET{'iot_device_table|ts_data','meter_data|readings'} Two loader sessions are active: one for the iot_device_table table and ts_data column, and one for the meter_data table and readings column. The following statement returns the handles in table format: SELECT * FROM TABLE(tsl_activehandles()) AS t(al) – output is below: al iot_device_table|ts_data al meter_data|readings © 2016 IBM Corporation 55

Display Time Series Storage Space Usage - TSInfo
Find the amount of storage space used by a time series by running the new TSInfo() function. Customize the level of detail of the information: Details about element page usage, such as the Number of pages Number of bytes Amount of free space Number of null pages Return information about other time series properties: The origin The type of values The containers. TSInfo function The TSInfo function returns information about a time series and the storage that is used by the time series. Syntax TSInfo( ts TimeSeries, control BSON default NULL, begin_tstamp DATETIME YEAR TO FRACTION(5) default NULL, end_tstamp DATETIME YEAR TO FRACTION(5) default NULL) returns BSON; Read syntax diagramSkip visual syntax diagram Syntax of control >>-{ > .-, V | >--+---smallElementPage--:--+-Boolean > | '-| smallElementPage Options |-' | +-largeElementPage--:--+-Boolean | '-| largeElementPage Options |-' | +-element--:--+-Boolean | '-| element Options |-' | +-containerPageSize--:--Boolean +-btreeLeafSlotSize--:--Boolean +-baseTableSize--:--Boolean +-totalIntervalCount--:--Boolean +-intervalCount--:--+-Boolean | '-| intervalCount Options |-' | +-metadata--:--+-Boolean | '-| metadata Options |-' | +-totalPages--:--Boolean +-totalUserSlots--:--Boolean +-totalSlots--:--Boolean +-totalUserSize--:--Boolean +-totalSize--:--Boolean +-totalFree--:--Boolean +-pageSizeDistribution--:--Boolean +-memoryUsage--:--+-Boolean | '-| memoryUsage Options |-' | '-rollingWindows--:--+-Boolean ' '-| rollingWindows Options |-' >--} >< Ts The name of the TimeSeries column. Control A BSON document that describes which values to return and the corresponding structure of the output document. Each field can have a Boolean value of true or false. Some fields can have subdocuments that refine the return value. Output values are in integers, unless otherwise indicated. The default document for the control parameter sets all values to true except for dormant rolling window containers: { smallElementPage:true, largeElementPage:true, element:true, containerPageSize:true, btreeLeafSlotSize:true, baseTableSize:true, totalIntervalCount:true, intervalCount:true, metadata:true, totalPages:true, totalUserSlots:true, totalSlots:true, totalUserSize:true, totalSize:true, totalFree:true, pageSizeDistribution:true, memoryUsage:true, rollingWindows:{active:true,dormant:false} } smallElementPage Information about pages that contain elements that are small enough to fit on one page. smallElementPage Options .-, V | |--{----+-count--:--Boolean }--| +-size--:--Boolean +-free--:--Boolean +-distribution--:--Boolean +-+-slot--: Boolean | '-header--:-' | .-, | | | | V | | | | '-{----+-count--:--Boolean-+-+--}-' | | '-size--:--Boolean--' | '-nullPage--:--+-Boolean ' '-{--count--:--Boolean--}-' The count field shows the total number of pages that contain small elements. The size field shows the total number of bytes on small element pages. The free field shows the total number of bytes of free space on all small element pages. The distribution field shows the fullness of small element pages. See Distributions. The slot field shows two fields. The count field shows the total number of small element slots in the time series: The size field shows the total number of bytes in small element slots, except header slots and large element page directories. The header field shows two fields. The count field shows the total number of header slots for small element pages. The size field shows the total number of bytes in small element header slots. The nullPage field shows the total number of pages that have null values for all element slots. largeElementPage Information about pages that contain elements that are too large to fit on one page. largeElementPage Options .-, V | |--{----+-count--:--Boolean }--| +-size--:--Boolean +-free--:--Boolean +-distribution--:--Boolean '-+-slot--: Boolean ' +-header--: | .-, | '-directory--:-' | V | | '-{----+-count--:--Boolean-+-+--}-' '-size--:--Boolean--' The count field shows the total number of pages that contain large elements. The size field shows the total number of bytes on large element pages. The free field shows the total number of bytes of free space on all large element pages. The distribution field shows the fullness of large element pages. See Distributions. The slot field shows two fields. The count field shows the total number of large element slots in the time series. The size field shows the total number of bytes in large element slots. The header field shows two fields. The count field shows the total number of header slots for large element pages. The size field shows the total number of bytes in large element header slots. The directory field shows two fields. The count field shows the total number of directory slots for large element pages. The size field shows the total number of bytes in large element directory slot. element Information about the number of physical elements. element Options .-, V | |--{----+-count--:--Boolean } | '-notNullCount--:--Boolean-' The count shows the total number of physical elements, including null slots. The notNullCount field shows the total number of non-null physical elements. containerPageSize The page size, in bytes, of containers. For example, 2048 or 4096. btreeLeafSlotSize The size, in bytes, of B-tree leaf slots that are used by the index on time series data. baseTableSize The size, in bytes, of the base table that contains the time series. Includes the size of any in-row time series data. totalIntervalCount The total number of partitions in rolling window containers. This value is not affected by the begin_stamp and end_stamp parameters or the setting of the rollingWindows field. intervalCount The number of active and dormant partitions in rolling window containers. intervalCount Options .-, V | |--{----+-active--:--Boolean } | '-dormant--:--Boolean-' The active field shows the number of active partitions in rolling window containers. The dormant field shows the number of dormant partitions in rolling window containers. metadata Information about the properties of the time series. metadata Options .-, V | |--{----+-origin--:--Boolean } | +-calendar--:--Boolean +-container--:--Boolean +-threshold--:--Boolean +-tsid--:--Boolean +-irregular--:--Boolean +-inmem--:--Boolean +-bigtsid--:--Boolean +-rollingWindow--:--Boolean--+ +-hertz--:--Boolean +-compression--:--Boolean----+ '-originalOrigin--:--Boolean-' The origin field shows the origin date of the time series. The output value is a string representation of a DATETIME data type in the following format: %Y-%m-%d %H:%M:%S.%F5. For example: :00: The calendar field shows the name of the calendar for the time series as a string value. The container field shows the name of the container for the time series as a string value. No value indicates that the time series is not stored in a container. The threshold field shows the threshold value of the time series. The tsid field shows the time series instance ID as a BIGINT value if the time series elements are stored in containers. The irregular field indicates whether the time series is irregular (true) or regular (false). The inmem field indicates whether the time series data is in-row (true) or in containers (false). The bigtsid field indicates whether the time series instance ID is a BIGINT value (true) or an INTEGER value (false). The rollingWindow field indicates whether the time series data is stored in rolling window containers (true) or not (false). The hertz field shows the number of records of hertz data per second that are stored. The value 0 indicates that the time series does not store hertz data. The compression field shows the compression definition as a string value for compressed time series data. No value indicates that the time series is not compressed. The originalOrigin field shows the original origin for a regular time series if the origin was reset by the SetOrigin function; otherwise, this value is the same as the value of the origin field. The output value is a string representation of a DATETIME data type in the following format: %Y-%m- %d %H:%M:%S.%F5. For example: :00: totalPages The total number of element pages that are used by the time series. Equivalent to the number of small element pages plus the number of large element pages. totalUserSlots The total number of user slots that are used by the time series. Equivalent to the number of small element page slots plus the number of large element page directory slots. totalSlots The total number of slots that are used by the time series. Equivalent to the sum of the number of small element page and header slots and large element page, directory, and header slots. totalUserSize The total size, in bytes, of the user pages that are used by the time series. Equivalent to the sum of the size of the small element page slots and the large element page slots. totalSize The total size, in bytes, of the pages that are used by the time series. Equivalent to the sum of the size of the small element pages and the large element pages. totalFree The total size, in bytes, of free space on both small and large element pages. pageSizeDistribution The distribution of the fullness of element pages. Equivalent to the sum of the small and large element page distributions. See Distributions. memoryUsage The amount of shared memory, in bytes, that contains the results of time series functions. rollingWindows Controls whether storage information is returned for rolling window containers or standard containers. If you set the rollingWindows field to false, storage information is returned for standard containers. If you set the rollingWindows field to true, storage information is returned for both active and dormant windows in rolling window containers, but not for standard containers. The default is to return information about only the active windows in rolling window containers. The output for the rollingWindows field shows the input value as a string. rollingWindows Options The active field controls whether information is returned about active windows in rolling window containers. The dormant field controls whether information is returned about dormant windows in rolling window containers. begin_tstamp The beginning point of the range. Can be NULL, which represents the first element in the time series. If a time stamp is specified, the output value is a string representation of a DATETIME data type in the following format: %Y-%m-%d %H:%M:%S.%F5. For example: :00: end_tstamp The end point of the range. Can be NULL, which represents the last element in the time series. If a time stamp is specified, the output value is a string representation of a DATETIME data type in the following format: %Y-%m-%d %H:%M:%S.%F5. For example: :00: Distributions Distributions are an array of 10 positions of integer values that each represent a 10% range of space usage. The value that is returned in each position of the array is the number of pages that are the corresponding percentage full. The following table shows the array positions and the corresponding percentage ranges. Table 1. Distribution percentage rangesArray Percentage 0-10% % % % % % % % % % For example, if a time series used 53 small element pages in a container and 48 of the pages are between 95% and 100% full, then the value in the ninth array position is 48. The other five pages are represented in other array positions: smallElementPage:{distribution:[ 1, 0, 0, 3, 0, 1, 0, 0, 0, 48]} One page is 0-10% full, three pages are 31-40% full, one page is 51-60% full, and 48 pages are % full. Usage Run the TSInfo function to return information about a time series. By default, the TSInfo function returns detailed information about the storage that is used by the time series and the properties of the time series. Limit the information that is returned by the TSInfo function by specifying the fields that you want in the control parameter. Include time stamps for the begin_stamp and end_stamp parameters to return information about the time series elements in a specific time range. The TSInfo function can be CPU intensive, depending on the number of elements for which to gather information and the type of information to return. For example, returning the number of hertz or compressed elements is the most CPU-intensive operation. Use the following rules for constructing the control parameter: If any fields that are listed have a value of true, all fields that are not listed are omitted. If you want only specific fields, list only those fields, with the value true. Any subdocuments for the fields that you list are automatically included. Fields that are not listed are not included. For example, the value {smallElementPage:true} returns all the values for smallElementPage and no other information. If you want to return only specific fields but exclude specific fields in subdocuments, list the subdocuments with a value of false and at least one other field with a value of true. For example, the value {smallElementPage:{count:true, size:false}} returns all the values for smallElementPage except for the value of the size field. If all fields that are listed have a value of false, all fields that are not listed are included. If you want to return all fields except for specific fields, list the fields to omit with a value of false and do not list any fields with a value of true. For example, the value {smallElementPage:false, largeElementPage:false} returns the values for all fields except smallElementPage and largeElementPage. Important: Misspelled field names in the control parameter are ignored without an error. If you do not receive the results that you expect, check the spelling of the field names in the control parameter. Returns A BSON document with the requested field-name value pairs. Example: Default information The following statement returns the default information about a time series instance: SELECT meter_id, tsinfo(readings)::json::lvarchar AS info FROM sensor_data WHERE meter_id = 2011; meter_id info {"smallElementPage":{"count":2046,"size": ,"free":174012, "distribution":[0,0,0,0,1,0,0,0,0,2045],"slot":{"count":45000,"size": }, "header":{"count":2046,"size":85932},"nullPage":{"count":0}},"largeElementPage": {"count":0,"size":0,"free":0,"distribution":[0,0,0,0,0,0,0,0,0,0],"slot":{ "count":0,"size":0},"header":{"count":0,"size":0},"directory":{"count":0,"size": 0}},"element":{"count":45000,"notNullCount":45000},"containerPageSize":4096, "btreeLeafSlotSize":19,"baseTableSize":92,"totalIntervalCount":0,"intervalCount": {"active":0,"dormant":0},"metadata":{"origin":" :00: ", "calendar":"ts_1sec","container":"container4k_hz_3","threshold":0,"tsid":41, "irregular":true,"inmem":false,"bigtsid":true,"rollingWindow":false,"hertz":0, "compression":"","originalOrigin":" :00: "},"totalPages":2046, "totalUserSlots":45000,"totalSlots":47046,"totalUserSize": ,"totalSize": ,"totalFree":174012,"pageSizeDistribution":[0,0,0,0,1,0,0,0,0,2045], "memoryUsage":{"count":0,"size":0},"rollingWindows":{"active":true}} Example: Small element page count for a time range The following statement returns the small element page count for two time series instances over an hour: SELECT meter_id,info::json::lvarchar AS info, bson_value_bigint(info, 'smallElementPage.count') AS count FROM(SELECT skip 0 meter_id, tsinfo(readings, '{smallElementPage:{count:true}}'::json::bson, ' :00: ', ' :00: ') FROM ts WHERE meter_id <= 2) AS ti(meter_id, info); meter_id info {"smallElementPage":{"count":0},"rollingWindows":{"active":true}, "begin_tstamp":" :00: ", "end_tstamp":" :00: "} count meter_id Example: Total number of pages The following statement returns the total number of pages for two time series instances: SELECT meter_id, info::json::lvarchar AS info, bson_value_bigint(info, 'totalPages') AS totalpages FROM (SELECT skip 0 meter_id, tsinfo(readings, '{totalPages:true}'::json::bson) FROM devices WHERE meter_id <= 2) AS ti(meter_id, info); info {"totalPages":52,"rollingWindows":{"active":true}} totalpages info {"totalPages":32,"rollingWindows":{"active":true}} totalpages Example: Metadata The following statement returns the metadata information for two time series instances: SELECT meter_id,info::json::lvarchar FROM (SELECT skip 0 meter_id, tsinfo(readings, '{metadata:true}'::json::bson) FROM devices WHERE meter_id <= 2) AS ti(meter_id, info); info {"metadata":{"origin":" :00: ","calendar": "ts_1min","container":"container4k_1","threshold":0,"tsid":17,"irregular":true, "inmem":false,"bigtsid":true,"rollingWindow":true,"hertz":0,"compression":"", "originalOrigin":" :00: "},"rollingWindows":{"active":true}} "ts_1min","container":"container4k_2","threshold":0,"tsid":18,"irregular":false, "originalOrigin":" :00: "},"rollingWindows":{"active":true}} © 2016 IBM Corporation 56

TSInfo function (1) Syntax: TSInfo( ts TimeSeries,
control BSON default NULL, begin_tstamp DATETIME YEAR TO FRACTION(5) default NULL, end_tstamp DATETIME YEAR TO FRACTION(5) default NULL) returns BSON; ts - TimeSeries column name control - BSON Document describing return values and the output document’s corresponding structure: Each field has a Boolean value of either true or false. Some fields can have subdocuments that refine the return value. Output values are in integers, unless otherwise indicated. Default control parameter document sets all values to true Except for dormant rolling window containers. Document structure is on the next several slides: © 2016 IBM Corporation

TSInfo function (2) { smallElementPage:true, } largeElementPage:true,
element:true, containerPageSize:true, btreeLeafSlotSize:true, baseTableSize:true, totalIntervalCount:true, intervalCount:true, metadata:true, totalPages:true, totalUserSlots:true, totalSlots:true, totalUserSize:true, totalSize:true, totalFree:true, pageSizeDistribution:true, memoryUsage:true, rollingWindows:{active:true,dormant:false} } © 2016 IBM Corporation

TSInfo– smallElementpage parameter options (1)
.. smallElementPage - Page info containing elements small enough to fit on one page. .-, V | |--{----+-count--:--boolean }--| +-size--:--boolean +-free--:--boolean +-distribution--:--boolean +-+-slot--: boolean | '-header--:-' | .-, | | | | V | | | | '-{----+-count--:--boolean-+-+--}-' | | '-size--:- -boolean----' | '-nullPage--:--+-boolean ' '-{--count--:--boolean--}-' © 2016 IBM Corporation

TSInfo – smallElementpage parameter options (2)
count - total number of pages that contain small elements. size - total number of bytes on small element pages. free - total number of bytes of free space on all small element pages. distribution - fullness of small element pages. See Distributions. slot - shows two fields. count - total number of small element slots in the time series. size - total number of bytes in small element slots: Not included are header slots and large element page directories. header - shows two fields. count - total number of header slots for small element pages. size - total number of bytes in small element header slots. nullPage - total number of pages having null values in all element slots. © 2016 IBM Corporation

TSInfo – largeElementpage parameter options (1)
.. largeElementPage - Information about pages that contain elements that are too large to fit on one page. .-, V | |--{----+-count--:--boolean }--| +-size--:--boolean +-free--:--boolean +-distribution--:--boolean +-+-slot--: boolean | '-header--:-' | .-, | | | ‘-directory-- - | V | | '-{----+-count--:--boolean-+-+--}-' | | '-size--:- -boolean----' | '-nullPage--:--+-boolean ' '-{--count--:--boolean--}-' © 2016 IBM Corporation

TSInfo – largeElementpage parameter options (2)
count - total number of pages that contain large elements. size - total number of bytes on large element pages. free - total number of bytes of free space on all large element pages. distribution - fullness of large element pages. See Distributions. slot - shows two fields. count - total number of large element slots in the time series. size - total number of bytes in large element slots: Not included are header slots and large element page directories. header - shows two fields. count - total number of header slots for large element pages. size - total number of bytes in large element header slots. directory - shows two fields. count - total number of directory slots for large element pages. size - total number of bytes in large element directory slots. © 2016 IBM Corporation

TSInfo – element parameter options
element - Info about the number of physical elements. .-, V | |--{----+-count--:--Boolean } | '-notNullCount--:--Boolean-' count - total number of physical elements, including null slots. notNullCount - total number of non-null physical elements. © 2016 IBM Corporation

TSInfo parameters (cont’d)
containerPageSize Container page size in bytes. For example, 2048 or 4096. btreeLeafSlotSize B-tree leaf slots page size in bytes used by the index on time series data. baseTableSize Base table page size in bytes containing the time series. Includes the size of any in-row time series data. totalIntervalCount The total number of partitions in rolling window containers. This value is not affected by the begin_stamp and end_stamp parameters or the setting of the rollingWindows field. intervalCount The number of active and dormant partitions in rolling window containers. © 2016 IBM Corporation 64

TSInfo – intervalCount parameter
Number of active and dormant partitions in rolling window containers. intervalCount options .-, V | |--{----+-active--:--boolean } | '-dormant--:--boolean--' active - number of active partitions in rolling window containers. dormant - number of dormant partitions in rolling window containers © 2016 IBM Corporation 65

TSInfo – metadata parameter (1)
metadata - Information about the properties of the time series. metadata Options .-, V | |--{----+-origin--:--boolean } | +-calendar--:--boolean +-container--:--boolean +-threshold--:--boolean +-tsid--:--boolean +-irregular--:--boolean +-inmem--:--boolean +-bigtsid--:--boolean +-rollingWindow--:--boolean--+ +-hertz--:--boolean +-compression--:--boolean----+ '-originalOrigin--:--boolean-----' © 2016 IBM Corporation

TSInfo – metadata parameter (2)
origin The origin date of the time series. Output value is a DATETIME data type string representation in the following format: %Y-%m-%d %H:%M:%S.%F5. :00: calendar name of the calendar for the time series as a string value. container Name of the time series container as a string value. No value indicates that the time series is not stored in a container. threshold The threshold value of the time series. tsid The time series instance ID as a BIGINT value But only if the time series elements are stored in containers. © 2016 IBM Corporation

TSInfo - metadata parameters (3)
irregular Is the time series: Irregular - True Regular – False inmem Is the time series data stored: In row - True In containers - False bigtsid Is the time series instance ID A BIGINT value - True A INTEGER value - False rollingWindow Is the time series data is stored in Rolling Window Container - True Or not - False hertz The number of stored records of hertz data per second The value 0 indicates that the time series does not store hertz data. © 2016 IBM Corporation 68

TSInfo – metadata parameters (4)
compression The compression definition as a string value for compressed time series data. No value indicates that the time series is not compressed. originalOrigin The original origin for a regular time series if the origin was reset by the SetOrigin function; otherwise, this value is the same as the value of the origin field. The output value is a string representation of a DATETIME data type in the following format: %Y-%m-%d %H:%M:%S.%F5. For example: :00: © 2016 IBM Corporation 69

totalPages The total number of used time series element pages Equivalent to the number of small element pages plus the number of large element pages. totalUserSlots The total number of user slots that are used by the time series. Equivalent to the number of small element page slots plus the number of large element page directory slots. totalSlots The total number of slots that are used by the time series. Equivalent to the sum of the number of small element page and header slots and large element page, directory, and header slots. totalUserSize The total size, in bytes, of the user pages that are used by the time series. Equivalent to the sum of the size of the small element page slots and the large element page slots. totalSize The total size, in bytes, of the pages that are used by the time series. Equivalent to the sum of the size of the small element pages and the large element pages. © 2016 IBM Corporation

totalFree The total bytes size of free space on both small and large element pages. pageSizeDistribution The distribution of the fullness of element pages. Equivalent to the sum of the small and large element page distributions. See Distributions below. memoryUsage The byte amount of shared memory containing the results of time series functions © 2016 IBM Corporation

TSInfo – rollingWindows parameters
Controls whether storage information is returned for rolling window containers or standard containers. If false, storage information is returned for standard containers. If true, storage information is returned for both active and dormant windows in rolling window containers, but not for standard containers. (Default) The output for the rollingWindows field shows the input value as a string. rollingWindows options .-, V | |--{----+-active--:--boolean } | '-dormant--:--boolean-' active Controls whether info is returned on active windows in rolling window containers. dormant Controls whether info is returned on dormant windows in rolling window containers. © 2016 IBM Corporation

begin_tstamp The beginning point of the range. Can be NULL, which represents the first element in the time series. If a time stamp is specified, the output value is a string representation of a DATETIME data type in the following format: %Y-%m-%d %H:%M:%S.%F5. For example: :00: end_tstamp The end point of the range. Can be NULL, which represents the last element in the time series. © 2016 IBM Corporation

TSInfo - Distributions
An array of 10 positions of integer values that each represent a 10% range of space usage. The value returned in each array position is the number of pages that are the corresponding percentage full. The following table shows the array positions and the percentage ranges: If a time series uses 53 small element pages in a container and 48 of the pages are 95%- 100% full, then the value in the ninth array position is 48. The other five pages are represented in other array positions: smallElementPage:{distribution:[ 1, 0, 0, 3, 0, 1, 0, 0, 0, 48]} One page is 0-10% full, three pages are 31-40% full, one page is 51-60% full, and 48 pages are % full. 1 2 3 4 5 6 7 8 9 0-10% 11-20% 21-30% 31-40% 41-50% 51-60% 61-70% 71-80% 81-90% 91-100% The above example is a code snippet and not the whole syntax. © 2016 IBM Corporation 74

TSInfo – Time Series Information Usage (1)
Default, TSInfo returns detailed information about the storage that is used by the time series and the properties of the time series. Limit the information that is returned by TSInfo by specifying the fields that you want in the control parameter: Include time stamps for the begin_stamp and end_stamp parameters to return information about the time series elements in a specific time range. TSInfo can be CPU intensive, depending on the number of elements to gather info on and the type of info to return: Returning the number of hertz or compressed elements is the most CPU-intensive operation. © 2016 IBM Corporation

TSInfo – Control Parameter Usage
Rules If any listed fields have a value of true, all fields that are not listed are omitted. If you want only specific fields, list only those fields, with the value true. Any subdocuments for the fields that you list are automatically included. Fields that are not listed are not included. For example, the value {smallElementPage:true} returns all the values for smallElementPage and no other information. If you want to return only specific fields but exclude specific fields in subdocuments, list the subdocuments with a value of false and at least one other field with a value of true. For example, the value {smallElementPage:{count:true, size:false}} returns all the values for smallElementPage except for the value of the size field. If all fields listed have a value of false, all fields that are not listed are included. If you want to return all fields except for specific fields, list the fields to omit with a value of false and do not list any fields with a value of true. For example, the value {smallElementPage:false, largeElementPage:false} returns the values for all fields except smallElementPage and largeElementPage. © 2016 IBM Corporation

TSInfo – Control Parameter Usage (2) / Return Info
Important: Misspelled field names in the control parameter are ignored without an error. If you do not receive the results that you expect, check the spelling of the field names in the control parameter. Returns A BSON document with the requested field-name value pairs. © 2016 IBM Corporation

Output Examples TSInfo (1)
Return default information about a time series instance: SELECT meter_id, tsinfo(readings)::json::lvarchar AS info FROM sensor_data WHERE meter_id = 2011; meter_id info {"smallElementPage":{"count":2046,"size": ,"free":174012, "distribution":[0,0,0,0,1,0,0,0,0,2045],"slot":{"count":45000,"size": }, "header":{"count":2046,"size":85932},"nullPage":{"count":0}},"largeElementPage": {"count":0,"size":0,"free":0,"distribution":[0,0,0,0,0,0,0,0,0,0],"slot":{ "count":0,"size":0},"header":{"count":0,"size":0},"directory":{"count":0,"size": 0}},"element":{"count":45000,"notNullCount":45000},"containerPageSize":4096, "btreeLeafSlotSize":19,"baseTableSize":92,"totalIntervalCount":0,"intervalCount": {"active":0,"dormant":0},"metadata":{"origin":" :00: ", "calendar":"ts_1sec","container":"container4k_hz_3","threshold":0,"tsid":41, "irregular":true,"inmem":false,"bigtsid":true,"rollingWindow":false,"hertz":0, "compression":"","originalOrigin":" :00: "},"totalPages":2046, "totalUserSlots":45000,"totalSlots":47046,"totalUserSize": ,"totalSize": ,"totalFree":174012,"pageSizeDistribution":[0,0,0,0,1,0,0,0,0,2045], "memoryUsage":{"count":0,"size":0},"rollingWindows":{"active":true}} Notice the double casting in the select statement above. © 2016 IBM Corporation 78

Return the small element page count for two time series instances over an hour: SELECT meter_id,info::json::lvarchar AS info, bson_value_bigint(info, 'smallElementPage.count') AS count FROM (SELECT skip 0 meter_id, tsinfo(readings, '{smallElementPage:{count:true}}'::json::bson, ' :00: ', ' :00: ') FROM ts WHERE meter_id <= 2) AS ti(meter_id, info); meter_id info {"smallElementPage":{"count":0},"rollingWindows":{"active":true}, "begin_tstamp":" :00: ", "end_tstamp":" :00: "} count meter_id © 2016 IBM Corporation

Return the total number of pages for two time series instances: SELECT meter_id, info::json::lvarchar AS info, bson_value_bigint(info, 'totalPages') AS totalpages FROM (SELECT skip 0 meter_id, tsinfo(readings, '{totalPages:true}'::json::bson) FROM devices WHERE meter_id <= 2) AS ti(meter_id, info); meter_id info {"totalPages":52,"rollingWindows":{"active":true}} totalpages meter_id info {"totalPages":32,"rollingWindows":{"active":true}} totalpages © 2016 IBM Corporation

Return the metadata information for two time series instances: SELECT meter_id,info::json::lvarchar FROM (SELECT skip 0 meter_id, tsinfo(readings, '{metadata:true}'::json::bson) FROM devices WHERE meter_id <= 2) AS ti(meter_id, info); meter_id info {"metadata":{"origin":" :00: ","calendar": "ts_1min","container":"container4k_1","threshold":0,"tsid":17,"irregular":true, "inmem":false,"bigtsid":true,"rollingWindow":true,"hertz":0,"compression":"", "originalOrigin":" :00: "},"rollingWindows":{"active":true}} meter_id "ts_1min","container":"container4k_2","threshold":0,"tsid":18,"irregular":false, "originalOrigin":" :00: "},"rollingWindows":{"active":true}} © 2016 IBM Corporation

Time Series Data Queries
Analyze time series data for matches to patterns Search time series data for matches to a specific pattern of values: If you identify a sequence of four values that indicate a problem, you can search for other sequences of four values that are similar to the original sequence of values. You run the function TSPatternMatch() to find pattern matches. You specify the margin of error and whether to search through consecutive sequences of values or through every possible subsequence of values. You can create a pattern matching index to improve query performance by running the function TSCreatePatternIndex(). © 2016 IBM Corporation 82

Time Series Pattern Matching Searches (1)
Search time series data for matches to a user supplied particular pattern of values related to a business situation Pattern matching searches do not discover patterns in time series data. For example, after a data pattern of abnormal electricity usage indicating an outage is identified, you can search for matches to that pattern to find other outages. A pattern is a sequence of numeric values in a field within the TimeSeries subtype. A search pattern can be specified as a time range in a specific time series or as a list of numeric values: A match is a sequence of values from a target time series that conform to the search criteria. A matching pattern has the same number of values as the search pattern. A match is returned as a primary key value, a time range, and a similarity score. © 2016 IBM Corporation

Search for pattern matches via TSPatternMatch() function, specifying: Target time series instance. The search time interval. How closely the data must match the specified pattern. It is possible to create a pattern matching search index on a time series instance to improve query performance via the function TSCreatePatternIndex() for each time series instance that you want to index. Programmers can control how precisely the data is indexed. © 2016 IBM Corporation

The following TimeSeries data type, table, and data: CREATE ROW TYPE myrow(tstamp datetime year to fraction(5), value1 real); CREATE TABLE tsdata(id int primary key, ts1 timeseries(myrow)); INSERT INTO tsdata VALUES(1000, "origin( :00: ), calendar(ts_1month), container(container), threshold(0), regular, [(1),(1),(55),(55),(55),(55),(1),(45),(45),(45),(45),(1)]"); The table on the next slide shows the time series data in the ts1 table: There are some other requirements to meet this exactly. Requirements for pattern matching searches The table and time series definition must meet the requirements for pattern matching queries and the appropriate extensions must be registered. Pattern matching criteria When you run a pattern matching search, you specify to method to evaluate possible matches and the margin of error between the search pattern and matching values. Indexes on patterns You can create a pattern matching index on a time series to speed pattern matching queries. TSPatternMatch function The TSPatternMatch function returns matches to a specified pattern of values. getPatternFromTS function The getPatternFromTS function returns a list of values that you can use as a search pattern. TSPMatchRelease function The TSPMatchRelease function returns the internal version number and build date for the TimeSeries Pattern Matching extension. TSCreatePatternIndex function The TSCreatePatternIndex function indexes time series data for pattern matching searches. TSDropPatternIndex function The TSDropPatternIndex function drops the specified pattern matching index. TSPIndexCleanup procedure The TSPIndexCleanup procedure drop all pattern matching indexes and internal tables. TSPIndexRelease function The TSPIndexRelease function returns the internal version number and build date for the TimeSeries Pattern Matching Index extension. These can be found in the Time Series Users Guide. © 2016 IBM Corporation 85

tstamp value1 :00:00 1 :00:00 :00:00 55 :00:00 :00:00 :00:00 :00:00 :00:00 45 :00:00 :00:00 :00:00 :00:00 You have an interesting data pattern of (55),(55),(55),(55) and want to find matches to it in the value1 column. The sequence of values in the time range :00:00 to :00:00 match the pattern exactly. © 2016 IBM Corporation 86

Select (clip) Time Series Data Columns - ProjectedClip
You can extract data between two timepoints in a time series and return a new time series that contains only the specified columns of the original time series. The new ProjectedClip() function will clip time series data from only the columns of the TimeSeries data type that you specify. The data loaded into your time series might be configured to store a null value when a value does not differ from the previous value. If you have a low frequency of non-null values, you can replace null values with the previous non-null values in the output time series: Replace only the first value for a column, if that value is null. Append (lf) to the column name in the column list to designate its low frequency. Replace all null values with the corresponding previous non-null values. Append (nn) to the column name in the column list to designate a column with no null return values. © 2016 IBM Corporation

Select (clip) Columns – ProjectedClip() (1)
Calls and Arguments: ProjectedClip( ts TimeSeries, begin_stamp DATETIME YEAR TO FRACTION(5), end_stamp DATETIME YEAR TO FRACTION(5), flag INTEGER DEFAULT 0) returns TimeSeries; flag INTEGER DEFAULT 0, column_list LVARCHAR) © 2016 IBM Corporation

ts The time series to clip. begin_stamp The beginning point of the range. Can be NULL, which indicates the origin of the time series. end_stamp The end point of the range. Can be NULL, which indicates the last value of the time series. flag (optional) The configuration of the resulting time series. column_list (optional) A list of column names from the input time series to include in the output time series. Separate column names with a comma. Append (lf) to the column name to designate a low frequency column. Append (nn) to the column name to designate a column with no null return values. © 2016 IBM Corporation

ProjectedClip() returns a column subset in the input time series instead of all the columns. When executed, ProjectedClip() casts the results to an existing output time series. The rules for defining the output time series depend on whether you include a column list. If a column list is not included: The names and corresponding data types of the columns in the output time series must be the same as in the input time series. The output time series can have fewer columns than the input time series. Columns from the input time series are mapped by name to the corresponding columns in the output time series. If a column list is included, the following rules apply: The column names and corresponding data types in the column list must match the input time series. The order and number of columns can differ. The number of columns and corresponding data types in the output time series must match the column list. The column names can differ. © 2016 IBM Corporation

Column values from the input time series are written to the output time series in the order that is specified by the column list. The data loaded into your time series might be configured to store a null value when a value does not differ from the previous value. If no previous non-null value exists for a low frequency or no nulls column, NULL is returned. For example, if you have rolling window containers, NULL is returned when the last non-null value is no longer in an active window. Also, the last non-null value is not returned if the first returned value is a null element, which does not have a time stamp or values for any columns. © 2016 IBM Corporation 91

Select (clip) Columns – ProjectedClip() (5) Return Data
Returned data is the output time series to which the function is cast Contains data from only the requested range and columns. The output time series has the same calendar as the input time series, but it can have a different origin and number of entries. Specific examples in the speaker notes. Examples In the following examples, the input time series has the following TimeSeries data type definition: CREATE ROW TYPE ts ( tstamp DATETIME YEAR TO FRACTION(5), i01 INTEGER, i02 INTEGER, i03 INTEGER i04 INTEGER, f01 FLOAT, f02 FLOAT); The input time series has the following time series data: tstamp i01 i02 i03 f01 f02 :00: null null :00: null null null :00: null null null :00: null null null :00: :00: null null :00: null null :00: null Example: Include a column list The following query specifies to clip values from three columns in the ts time series and return the results in the pc_row time series: ProjectedClip(ts, ' :00:00', ' :00:00', 0, 'i01,i02,f02')::TIMESTAMP(pc_row) The pc_row time series has the following structure: CREATE ROW TYPE pc_row ( value1 INTEGER, value2 INTEGER, value3 FLOAT); The names of the columns in the column list and the pc_row times series differ, but the data types and order of the columns are the same: The value1 column, an INTEGER, maps to the i01 column. The value2 column, an INTEGER, maps to the i02 column. The value3 column, a FLOAT, maps to the f02 column. The ProjectedClip function returns the following data in the pc_row time series: tstamp value1 value2 value3 :00: null null :00: null null :00: :00: null null :00: null Example: Omit a column list The following query specifies to clip values from the ts time series and return the results in the pc_row time series: 0)::TIMESTAMP(pc_row)' When you do not include a column list, the names, data types, and order of the columns in the pc_row time series must be the same as in the ts time series. For this example, the pc_row time series has the following structure: f01 FLOAT); The difference between the pc_row time series in the previous example and this pc_row time series is that the column names in this pc_row time series are the same as the column names in the ts time series. tstamp i01 i02 f02 :00: null null :00: null null :00: :00: null null :00: null 2.06 Example: Specify a low frequency column The following query specifies to clip values from the ts time series, treat the i02 column as a low- frequency column, and return the results in the pc_row time series: 'i01,i02(lf),f02')::TIMESTAMP(pc_row)' :00: null The first returned value for the i02 column is 200. The actual value for the i02 column for the timestamp :00:00 is NULL. The value 200 is the value for the i02 column for the time stamp :00:00, which is the last non-null value. Example: Specify no null columns The following query specifies to clip values from the ts time series, treat the i02 and the f02 columns as a no null columns, and return the results in the pc_row time series: 'i01,i02(nn),f02(nn)')::TIMESTAMP(pc_row)' :00: null :00: :00: For the i02 column, the first two values are 200 instead of NULL and the last two values are 204 instead of NULL. For the f02 column, the first values remain NULL because no previous non-null value exists. The fourth value for the f02 column is 2.04 instead of NULL. Parent topic: Time series SQL routines Related reference: Time series routines that run in parallel © 2016 IBM Corporation 92

Agenda - Spatiotemporal
Track moving objects Types of queries that can be issued Architecture Requirements Data types Functions Appendix A has the details. © 2016 IBM Corporation 94

Spatiotemporal With this feature, Informix merges its time series capabilities with its spatial data capabilities to produce storage and query capabilities from the use of standard Global Positioning Systems (GPS). GPS systems standardly use System Reference ID (SRID) 4326. © 2016 IBM Corporation 95

Track Moving Objects - General
A moving object, such as a vehicle, can be tracked by capturing location information for the object at regular time intervals via GPS data, for example. Use the new spatiotemporal search extension to index the data and then query on either time or on location to determine the relationship of one to the other. Query when an object was at a specified location, or at a specified time. You can also find the trajectory of a moving object over a range of time. The spatiotemporal search extension depends on the TimeSeries and spatial extensions: Store the spatiotemporal data in a TimeSeries data type with columns for longitude and latitude. Index and query spatiotemporal data with new spatiotemporal search functions. Query spatiotemporal data with time series and spatial routines. © 2016 IBM Corporation

Types of Queries The location of a moving object at a specific time.
Find the location of bus number 3435 at :30. The last known time and location of a specific moving object. Find the last known location of taxi number 324. When, in a time range, a moving object was in a region around a point of interest. When was a delivery truck within 100 meters of the Mom and Pop Diner between February 2-4, 2015. When a moving object was at a specific location. Find when object number 324 was at the Four Seasons Hotel. The trajectories, of a specific moving object for a time range. Find the trajectories of bus number 1543 between 9:00-17:00 yesterday. The trajectories of moving objects near a point of interest during a time range. Find which taxi driver witnessed an accident by finding which taxi was nearest to the location of the accident at 9:00. © 2016 IBM Corporation

Solution Architecture at a High Level
Informix already contains within it the necessary time series and spatial data types and spatial indexing functionality to store and process this data. The spatiotemporal solution builds upon the functionality and data types already found in the Informix TimeSeries and Spatial features. New is: An SQL function to index spatiotemporal data. SQL functions to query spatiotemporal data. SQL functions to remove spatiotemporal indexes. Spatiotemporal searches return location data as spatial data types from the Informix spatial extension. Customers provide client programs to do visualization, such as ESRI. © 2016 IBM Corporation

Requirements Hardware requirements common to Informix Dynamic Server.
Software requirements: Time Series feature automatically registered A database table containing a timeseries datatype is present. Spatial feature automatically registered and R-Tree feature present The OpenAdmin Tool scheduler is running: The Scheduler automatically registers the Spatiotemporal Search and Spatial extensions and runs the task to index spatiotemporal data. The name of the Spatiotemporal Search extension is sts.bld and it is in the $INFORMIXDIR/extend/sts.version/ directory, where version is the version number of the extension. If you have multiple CPU VP’s, set PRELOAD_DLL_FILE configuration parameter to the path for the spatiotemporal shared library file: PRELOAD_DLL_FILE $INFORMIXDIR/extend/sts.version/sts.bld version is the version number of the extension. Restart the database server after setting this. Hardware Requirements: © 2016 IBM Corporation 99

Time Series Requirements
Time series table must conform to the following requirements and restrictions: The first column must be a primary key column that represents an object ID and has a data type of INTEGER, CHAR, or VARCHAR. A composite primary key is not allowed. The second column must be a TimeSeries subtype column. The table can have more columns, however, any additional TimeSeries columns are not indexed. The table name must be unique. The table name is used to identify the spatiotemporal search. If the table name is longer than 100 bytes, the first 100 bytes of the name must be unique. © 2016 IBM Corporation

TimeSeries subtype requirements
The TimeSeries subtype must have the following structure: The first field is the time stamp field. This requirement is true of all TimeSeries subtypes. The second and third fields have a FLOAT data type to hold longitude and latitude data that are in the Spatial Reference System 4326 (WGS 84 standard). Optional additional fields can have any data type that is supported in a TimeSeries subtype. Time series definition restrictions. Although a regular time series is supported, an irregular time series is more appropriate for moving object data. Rolling window containers usage requires a manual rebuild of the spatiotemporal index when you attach or detach rolling window intervals. © 2016 IBM Corporation

Spatial data types for spatiotemporal searches (1)
Spatiotemporal search functions Either take a spatial data type as an argument or return a spatial data type. Use the following spatial data types: ST_Point A location that is specified by longitude (X) and latitude (Y) coordinate values. For functions that take an ST_Point argument, supply an X,Y coordinate value. ST_Points are also returned by some functions. ST_MultiLineString A set of one or more linestrings that represent a trajectory. ST_MultiLineStrings are returned by functions that find trajectories. ST_Geometry An abstract noninstantiable superclass. For functions that take an ST_Geometry, supply an ST_Point, ST_MultiPoint, ST_LineString, ST_MultiLineString, ST_Polygon, or ST_MultiPolygon value. Spatial data types require a spatial reference ID (SRID) that identifies the type of map projection system. For spatiotemporal search data, the SRID must be 4326, which is the SRID commonly used by global positioning system (GPS) devices. © 2016 IBM Corporation

Spatial data types for spatiotemporal searches (2)
Spatiotemporal search functions that take a distance parameter to define a region of interest take an optional unit of measure parameter: By default, the unit of measurement for distance is meters. You can specify a unit of measure that is listed in the unit_name column of the st_units_of_measure table. © 2016 IBM Corporation

Prerequisites To prepare for spatiotemporal searching:
Create and load a time series that conforms to the requirements for spatiotemporal search. Run the STS_Init() spatiotemporal search indexing process on the time series table, which starts the autosts Scheduler task that indexes the data. At task start, the following appears in the database server message log: INFO (STSMessage) Building trajectories for table_name is started. At task end, the following appears in the database server message log: INFO (STSMessage) Building trajectories for table_name is stopped. When the index is complete, you can run spatiotemporal searches. © 2016 IBM Corporation

Stopping spatiotemporal search indexing
When you stop spatiotemporal search indexing, you remove the spatiotemporal search internal tables, Scheduler tasks, and indexes. To stop spatiotemporal search indexing for a specific time series, run the STS_Cleanup() function and specify the time series table. To stop spatiotemporal search indexing for a database, run the STS_Cleanup() function without any parameters while connected to the database. To remove all spatiotemporal search software in the database in one step, run the following statement: EXECUTE FUNCTION SYSBldPrepare('sts*', 'drop'); © 2016 IBM Corporation

Functions/Routines for Spatiotemporal Searches (1)
Start spatiotemporal indexing for a table: STS_Init() Stop spatiotemporal search indexing and drop internal tables: STS_Cleanup() Find the position of an object at a specific time: STS_GetPosition() Find the most recent position of any object in the time series: STS_GetLastPosition() Find the first time in a time range when an object is near a position: STS_GetFirstTimeByPoint() Find the nearest object to a point at a specific time: STS_GetNearestObject() Find the exact trajectory for a time range: STS_GetTrajectory() Find the compressed trajectory for a time range: STS_GetCompactTrajectory() © 2016 IBM Corporation

The set of objects whose trajectories intersected a region during the time range: STS_GetIntersectSet() The set of objects that were within a region at a specific time: STS_GetLocWithinSet() The shortest distance between a point and the trajectory of an object during a time range: STS_TrajectoryDistance() Whether the trajectory remained within the boundary of the region for the time range: STS_TrajectoryWithin() Whether the trajectory crossed the boundary of the region in the time range: STS_TrajectoryCross() Whether the trajectory either crossed the boundary of the region or remained within the boundary of the region for the time range: STS_TrajectoryIntersect() © 2016 IBM Corporation

Agenda – JSON Manipulate JSON & BSON data via SQL
High Availability for MongoDB and REST clients Wire Listener configuration enhancements Wire Listener query support Enhanced user account management through the wire listener © 2016 IBM Corporation

High Availability for MongoDB and REST clients
To provide high availability to client applications: REST clients use a reverse proxy for multiple wire listeners. MongoDB clients use a HA cluster configuration for Informix database servers. Each database server in the cluster has a directly connected wire listener on the same computer as the database server that the wire listener is connected to and all wire listeners run on port To provide high availability between the wire listener and the Informix database server, use one of the following methods: Route the connection via the Connection Manager between the wire listener and the database server. Known methods Configure the url parameter in the wire listener configuration file to use one of the Informix JDBC Driver methods of connecting to a high-availability cluster, via a dynamic reading of the sqlhosts file. Has been enhanced in xC5 Reference to a reverse proxy below: Reverse Proxy: From Wikipedia: “In computer networks, a reverse proxy is a type of proxy server that retrieves resources on behalf of a client from one or more servers. These resources are then returned to the client as though they originated from the proxy server itself.[1] While a forward proxy acts as an intermediary for its associated clients to contact any server, a reverse proxy acts as an intermediary for its associated servers to be contacted by any client. Contents 1 Uses of reverse proxies 2 See also 3 References 4 External links Uses of reverse proxies Reverse proxies can hide the existence and characteristics of an origin server or servers. Application firewall features can protect against common web-based attacks. Without a reverse proxy, removing malware or initiating takedowns, for example, can become difficult. In the case of secure websites, a web server may not perform SSL encryption itself, but instead offloads the task to a reverse proxy that may be equipped with SSL acceleration hardware. (See SSL termination proxy.) A reverse proxy can distribute the load from incoming requests to several servers, with each server serving its own application area. In the case of reverse proxying in the neighborhood of web servers, the reverse proxy may have to rewrite the URL in each incoming request in order to match the relevant internal location of the requested resource. A reverse proxy can reduce load on its origin servers by caching static content, as well as dynamic content - also known as web acceleration. Proxy caches of this sort can often satisfy a considerable number of website requests, greatly reducing the load on the origin server(s). A reverse proxy can optimize content by compressing it in order to speed up loading times. In a technique known as "spoon-feed"[2] a dynamically generated page can be produced all at once and served to the reverse-proxy, which can then return it to the client a little bit at a time. The program that generates the page need not remain open, thus releasing server resources during the possibly extended time the client requires to complete the transfer. Reverse proxies can operate whenever multiple web-servers must be accessible via a single public IP address. The web servers listen on different ports in the same machine, with the same local IP address or, possibly, on different machines and different local IP addresses altogether. The reverse proxy analyzes each incoming request and delivers it to the right server within the local area network. Reverse proxies can perform A/B testing and multivariate testing without placing javascript tags or code into pages. Reverse proxy is also a concept used in search engine marketing to automatically instrument a destination website with usage tracking code that can be used for campaign reporting or campaign optimisation. It is a technique typically accepted as being bad practice.[citation needed]” See also Network address translation” References [1] "Forward and reverse proxies". The Apache Software Foundation. Retrieved 9 February 2011. [2] "squid-cache wiki entry on "SpoonFeeding"". Francesco Chemolli. Retrieved 9 February 2011. MongoDB reference above is reproduced in full below here as there are indications at the time of this writing that the referenced MongoDB page and content above may be changing. “MongoDB - Connecting Drivers to Replica Sets Note This legacy documentation does not necessarily reflect the current practices in MongoDB driver implementation, but may be useful for historical purposes. See the MongoDB Meta Driver for the current documentation of MongoDB driver implementation. Ideally a MongoDB driver can connect to a cluster of servers which represent a replica set, and automatically find the right set member with which to communicate. Failover should be automatic too. The general steps are: The user, when opening the connection, specifies host[:port] for one or more members of the set. Not all members need be specified. In fact the exact members of the set might change over time. This list for the connect call is the seed list. The driver then connects to all servers on the seed list, perhaps in parallel to minimize connect time. Send an isMaster command to each server. When the server is in replSet mode, it will return a hosts field with all members of the set that are potentially eligible to serve data. The client should cache this information. Ideally this refreshes too, as the set’s config could change over time. Choose a server with which to communicate. If ismaster == true, that server is primary for the set. This server can be used for writes and immediately consistent reads. If secondary == true, that server is not primary, but is available for eventually consistent reads. In this case, you can use the primary field to see which server the master should be. (If primary is not set, you may want to poll other nodes at random; it is conceivable that the member to which we are talking is partitioned from the other members, and thus it cannot determine who is primary on its own. This is unlikely but possible.) If an error occurs with the current connection, find the new primary and resume use there. For example, if we run the ismaster command on a non-primary server, we might get something like: > db.runCommand("ismaster") { "ismaster" : false, "secondary" : true, "hosts" : [ "ny1.acme.com", "ny2.acme.com", "sf1.acme.com" ], "passives" : [ "ny3.acme.com", "sf3.acme.com" "arbiters" : [ "sf2.acme.com", ] "primary" : "ny2.acme.com", "ok" : true } There are three servers with priority > 0 (ny1, ny2, and sf1), two passive servers (ny3 and sf3), and an arbiter (sf2). The primary should be ny2, but the driver should call isMaster on that server before it assumes it is.” For more information, see Dynamically reading the Informix sqlhosts file For Properties for connecting directly to an HDR pair of servers. From the JDBC 4.10 Driver Manual “Dynamically reading the Informix sqlhosts file IBM® Informix® JDBC Driver supports the JNDI (Java™ naming and directory interface). This support enables JDBC programs to access the Informix sqlhosts file. The sqlhosts file lets a client application find and connect to an Informix database server anywhere on the network. For more information about this file, see the IBM Informix Administrator's Guide for your database server. You can access sqlhosts data from a local file or from an LDAP server. The system administrator must load the sqlhosts data into the LDAP server using an Informix utility. Your CLASSPATH variable must reference the JNDI JAR (Java archive) files and the LDAP SPI (service provider interface) JAR files. You must use LDAP Version 3.0 or later, which supports the object class extensibleObject. You can use the sqlhosts file group option to specify the name of a database server group for the value of INFORMIXSERVER. The group option is useful with High-Availability Data Replication (HDR); list the primary and secondary database servers in the HDR pair sequentially. For more information on about how to set or use groups in sqlhosts file, see the IBM Informix Administrator's Guide. For more information about HDR, see Connections to the servers of a high-availability cluster. An unsigned applet cannot access the sqlhosts file or an LDAP server. For more information, see Using the driver in an applet.” Properties for connecting directly to an HDR pair of servers You can define your client application's connection URL or DataSource so that your application connects directly to an HDR pair of servers. If a connection attempt to the primary server fails, the client application can attempt to connect to the HDR secondary server. To connect directly to a primary server and HDR secondary server, include the following properties in the connection URL or DataSource: INFORMIXSERVER=primary_server_name INFORMIXSERVER_SECONDARY=secondary_server_name IFXHOST_SECONDARY=secondary_host_name PORTNO_SECONDARY=secondary_port_number USER=user_name PASSWORD=password ENABLE_HDRSWITCH=true If you are setting values in the DataSource, you must also include the following values: IFXHOST=primary_host_name PORTNO=primary_port_number When you are using a DataSource object, you can set and get the secondary server connection properties with setXXX() and getXXX() methods. These methods are listed with their corresponding connection property in Get and set Informix connection properties. You can manually redirect a connection to the secondary server in an HDR pair by editing the INFORMIXSERVER, PORTNO, and IFXHOST properties in the DataSource or by editing the INFORMIXSERVER property in the URL. Manual redirection requires editing the application code and then restarting the application. Example: Connecting to an HDR pair of servers The following example shows a connection URL for a primary server that is named server_1 and an HDR secondary server that is named server_2: jdbc:informix-sqli://my_host:my_port/my_database: INFORMIXSERVER=server_1; INFORMIXSERVER_SECONDARY=server_2; IFXHOST_SECONDARY=host2.example.com; PORTNO_SECONDARY=port_2; user=my_name; password=my_password; © 2016 IBM Corporation 111

Wire Listener Configuration File Enhancements
The wire listener configuration file can be any name, and there can be many of them created in a HA cluster, as long as each file is created in $INFORMIXDIR/etc and has a required .properties file name suffix. Use $INFORMIXDIR/etc/jsonListener-example.properties as a template. Copy it first; DON’T edit it directly. To include parameters in the wire listener, you must uncomment the row and customize parameters with the default values in the copy of the original template file. The url parameter is required. All other parameters are optional. Review the defaults for the following parameters and verify that they are appropriate for your environment: authentication.enable listener.type listener.port listener.hostName From the JDBC 4.10 Driver Manual “Dynamically reading the Informix sqlhosts file IBM® Informix® JDBC Driver supports the JNDI (Java™ naming and directory interface). This support enables JDBC programs to access the Informix sqlhosts file. The sqlhosts file lets a client application find and connect to an Informix database server anywhere on the network. For more information about this file, see the IBM Informix Administrator's Guide for your database server. You can access sqlhosts data from a local file or from an LDAP server. The system administrator must load the sqlhosts data into the LDAP server using an Informix utility. Your CLASSPATH variable must reference the JNDI JAR (Java archive) files and the LDAP SPI (service provider interface) JAR files. You must use LDAP Version 3.0 or later, which supports the object class extensibleObject. You can use the sqlhosts file group option to specify the name of a database server group for the value of INFORMIXSERVER. The group option is useful with High-Availability Data Replication (HDR); list the primary and secondary database servers in the HDR pair sequentially. For more information on about how to set or use groups in sqlhosts file, see the IBM Informix Administrator's Guide. For more information about HDR, see Connections to the servers of a high-availability cluster. An unsigned applet cannot access the sqlhosts file or an LDAP server. For more information, see Using the driver in an applet.” Properties for connecting directly to an HDR pair of servers You can define your client application's connection URL or DataSource so that your application connects directly to an HDR pair of servers. If a connection attempt to the primary server fails, the client application can attempt to connect to the HDR secondary server. To connect directly to a primary server and HDR secondary server, include the following properties in the connection URL or DataSource: INFORMIXSERVER=primary_server_name INFORMIXSERVER_SECONDARY=secondary_server_name IFXHOST_SECONDARY=secondary_host_name PORTNO_SECONDARY=secondary_port_number USER=user_name PASSWORD=password ENABLE_HDRSWITCH=true If you are setting values in the DataSource, you must also include the following values: IFXHOST=primary_host_name PORTNO=primary_port_number When you are using a DataSource object, you can set and get the secondary server connection properties with setXXX() and getXXX() methods. These methods are listed with their corresponding connection property in Get and set Informix connection properties. You can manually redirect a connection to the secondary server in an HDR pair by editing the INFORMIXSERVER, PORTNO, and IFXHOST properties in the DataSource or by editing the INFORMIXSERVER property in the URL. Manual redirection requires editing the application code and then restarting the application. Example: Connecting to an HDR pair of servers The following example shows a connection URL for a primary server that is named server_1 and an HDR secondary server that is named server_2: jdbc:informix-sqli://my_host:my_port/my_database: INFORMIXSERVER=server_1; INFORMIXSERVER_SECONDARY=server_2; IFXHOST_SECONDARY=host2.example.com; PORTNO_SECONDARY=port_2; user=my_name; password=my_password; © 2016 IBM Corporation 112

Wire Listener Configuration File – url Parameter
Specifies the host name, database server, user ID, and password that are used in connections to the database server. You must specify the sysmaster database in the url parameter; the wire listener uses sysmaster for administrative purposes. >>-url=--jdbc:informix-sqli://hostname:portnum--/sysmaster:-----> > >< '-USER=userid;--PASSWORD=password-' You can now include additional JDBC properties, each semi-colon ‘;’ separated with a semi-colon in the url parameter such as: INFORMIXCONTIME INFORMIXCONRETRY LOGINTIMEOUT IFX_SOC_TIMEOUT There are many parameters in the configuration file to consider. All of them except the url parameter are optional. Below is a list of these: Required url Setup and configuration documentIdAlgorithm include listener.onException listener.hostName listener.port listener.type response.documents.count.maximum response.documents.size.maximum sharding.enable Command and operation configuration collection.informix.options command.listDatabases.sizeStrategy update.client.strategy update.mode Database resource management database.buffer.enable database.create.enable database.dbspace database.locale.default database.log.enable database.share.close.enable database.share.enable dbspace.strategy fragment.count jdbc.afterNewConnectionCreation MongoDB compatibility compatible.maxBsonObjectSize.enable update.one.enable Performance insert.batch.enable insert.batch.queue.enable insert.batch.queue.flush.interval index.cache.enable index.cache.update.interval insert.preparedStatement.cache.enable preparedStatement.cache.enable preparedStatement.cache.size Security authentication.enable authentication.localhost.bypass.enable listener.http.accessControlAllowCredentials listener.http.accessControlAllowHeaders listener.http.accessControlAllowMethods listener.http.accessControlAllowOrigin listener.http.accessControlExposeHeaders listener.http.accessControlMaxAge listener.rest.cookie.domain listener.rest.cookie.httpOnly listener.rest.cookie.length listener.rest.cookie.name listener.rest.cookie.path listener.rest.cookie.secure security.sql.passthrough Wire listener resource management listener.idle.timeout listener.input.buffer.size listener.output.buffer.size listener.pool.keepAliveTime listener.pool.queue.size listener.pool.size.core listener.pool.size.maximum pool.connections.maximum pool.idle.timeout pool.idle.timeunit pool.semaphore.timeout pool.semaphore.timeunit pool.service.interval pool.service.timeunit pool.size.initial pool.size.minimum pool.size.maximum pool.type pool.typeMap.strategy Supported Environment Variables for the JDBC driver include (not shown are the GLS User’s Guide variables): From the xC5 Informix JDBC Driver User’s Guide : Supported Environment Variables for the JDBC driver include: APPENDISAM When set to TRUE, the APPENDISAM environment variable appends the ISAM Error code and message (if present) to the SQL Exception message, which is shown when .toString() or .getMessage() of an SQL Exception is called. The exception message is shown in the following format:<INFORMIX ERROR MESSAGE> (<INFORMIX CODE>) ISAM error: <ISAM MESSAGE>(<ISAM CODE>) CSM To specify that Communication Support Module is to be used. IBM Informix JDBC Driver 3.0 and later supports an encryption CSM. For more information, see Encryption options. DBANSIWARN When set to 1, checks for Informix extensions to ANSI-standard syntax DBSPACETEMP Specifies the dbspaces in which temporary tables are built DBTEMP Specifies the full path name of the directory into which you want IBM Informix Enterprise Gateway products to place their temporary files and temporary tables. The driver does not use this variable; it just passes the value to the server. DBUPSPACE Specifies the amount of disk space and memory that the UPDATE STATISTICS statement can use for sorting rows when it constructs multiple-column distributions, whether to sort with indexes, and whether to save the plan for calculating the column distributions in the sqexplain.out file. DELIMIDENT When set to Y, specifies that strings set off by double quotation marks are delimited identifiers ENABLE_TYPE_CACHE When set to TRUE, caches the data type information for opaque, distinct, or row data types. When a Struct or SQLData object inserts data into a column and getSQLTypeName() returns the type name, the driver uses the cached information instead of querying the database server. ENABLE_HDRSWITCH When set to TRUE, secondary server properties are used to connect to the secondary server if the primary server is unavailable. FET_BUF_SIZE Overrides the default setting for the size of the fetch buffer for all data except large objects. The default size is 4096 bytes. This variable is not supported in server-side JDBC. IFX_AUTOFREE When set to 1, specifies that the Statement.close() method does not require a network round trip to free the database server cursor resources if the cursor has already been closed in the database server. The database server automatically frees the cursor resources after the cursor is closed, either explicitly by the ResultSet.close() method or implicitly through the OPTOFC environment variable. After the cursor resources have been freed, the cursor can no longer be referenced. For more information, see The Auto Free feature. IFX_BATCHUPDATE_PER_SPEC When set to 1 (the default), returns the number of rows affected by the SQL statements executed in a batch operation by the executeBatch() method IFX_CODESETLOB If set to a number greater than or equal to 0, automates code-set conversion for TEXT and CLOB data types between client and database locales. The value of this variable determines whether code-set conversion is done in memory in or in temporary files. If set to 0, code-set conversion uses temporary files. If set to a value greater than 0, code-set conversion occurs in the memory of the client computer, and the value represents the number of bytes of memory allocated for the conversion. For more information, see Convert with the IFX_CODESETLOB environment variable. IFX_DIRECTIVES Determines whether the optimizer allows query optimization directives from within a query. This variable is set on the client. The driver does not use this variable; it just passes the value to the server. IFX_EXTDIRECTIVES Specifies whether the query optimizer allows external query optimization directives from the sysdirectives system catalog table to be applied to queries in existing applications. The default is OFF. Possible values: ON External optimizer directives accepted OFF External optimizer directives not accepted 1 External optimizer directives accepted 0 External optimizer directives not accepted IFX_GET_SMFLOAT_AS_FLOAT When set to 0 (the default), maps the Informix SMALLFLOAT data type to the JDBC REAL data type. This setting conforms to the JDBC specification. When set to 1, maps the Informix SMALLFLOAT data type to the JDBC FLOAT data type. This setting enables compatibility with earlier versions of IBM Informix JDBC Driver. IFX_ISOLATION_LEVEL Defines the degree of concurrency among processes that attempt to access the same rows simultaneously. Gets the value of theIFX_ISOLATION_LEVEL variable, which is specific to Informix. The default value is 2 (Committed Read). If the value has been set explicitly, it returns the set value. Returns: integer.Sets the value of the IFX_ISOLATION_LEVEL variable, which is specific to Informix. Possible values:0 Equivalent to TRANSACTION_NONE 1 Dirty Read (equivalent to TRANSACTION_READ_UNCOMMITTED), 2 Committed Read (equivalent to TRANSACTION_READ_COMMITTED), 3 Cursor Stability (equivalent to TRANSACTION_READ_COMMITTED), 4 Repeatable Read (equivalent to TRANSACTION_REPEATABLE_READ) 5 Committed Read LAST COMMITTED (equivalent to TRANSACTION_LAST_COMMITTED) 8 Equivalent to TRANSACTION_SERIALIZABLE Specifying U after the mode means retain update locks. (See the Important note following table.) For example, a value could be: 2U (equivalent to SET ISOLATION TO COMMITTED READ RETAIN UPDATE LOCKS The following example shows the code that you would use to specify an isolation level: conn.setTransactionIsolation (IfxConnection.TRANSACTION_LAST_COMMITTED); IFX_FLAT_UCSQ Overrides the global setting and directs the optimizer to use subquery flattening for all sessions. Default value is 1. IFX_LOCK_MODE_WAIT Application can use this property to override the default server process for accessing a locked row or table. Gets the value of the IFX_LOCK_MODE_WAIT variable, which is specific to Informix. The default value is 0 (do not wait for the lock). If the value has been set explicitly, it returns the set value. Returns: integer. Sets the value of the IFX_LOCK_MODE_WAIT variable, which is specific to Informix. Possible values: -1 WAIT until the lock is released. 0 DO NOT WAIT, end the operation, and return with error. nn WAIT for nn seconds for the lock to be released. IFX_PAD_VARCHAR Controls how data associated with a VARCHAR data type is transmitted to and from an Informix 9.4 or later server. Can be set either on the connection URL when using the Connection class or as a property when using the DataSource class. Valid values are 0 (the default) and 1.When set to 0, only the portion of the VARCHAR that contains data is transmitted (trailing spaces are stripped). When set to 1, the entire VARCHAR data structure is transmitted to and from the server. IFX_SET_FLOAT_AS_SMFLOAT When set to 0 (the default), maps the JDBC FLOAT data type to the Informix FLOAT data type. This setting conforms to the JDBC specification. When set to 1, maps the JDBC FLOAT data type to the Informix SMALLFLOAT data type. This setting enables compatibility with earlier versions of IBM Informix JDBC Driver. IFX_TRIMTRAILINGSPACES Removes trailing spaces. Default value is 1. IFX_USEPUT When set to 1, enables bulk inserts. For more information, see Perform bulk inserts. IFX_XASPEC When set to y, XA transactions with the same global transaction ID are tightly coupled and share the lock space. This only applies to XA connections and cannot be specified in a database URL. It can be specified by DataSource setter (See DataSource extensions.) or by setting a System (JVM) property with the same name. The DataSource property overrides the System property. Values for the properties other than y, Y, n, or N are ignored. IfxDataSource.getIfxIFX_XASPEC returns the final IFX_SPEC value, which is either y or n. For example if the value of DataSource IFX_XASPEC equals n and the value of the System IFX_XASPEC equals Y or y, n is returned. IFX_XASTDCOMPLIANCE_XAEND Specifies the behavior of XA_END when XA_RB* is returned.0 XID is not forgotten. Transaction is in Rollback Only state. This is XA_SPEC+ compliant and is the default behavior with Informix. 1 XID is forgotten. Transaction is Nonexistent. IFXHOST Sets the host name or host IP address IFXHOST_SECONDARY Sets the secondary host name or host IP address for HDR connection redirection INFORMIXCONRETRY Specifies the maximum number of additional connection attempts that can be made to each database server by the client during the time limit specified by the value of INFORMIXCONTIME INFORMIXCONTIME Sets the timeout period for an attempt to connect to the database server. If a connection attempt does not succeed in this time, the attempt is aborted and a connection error is reported. The default value is 0 seconds. This variable adds timeouts for blocking socket methods and for socket connections. INFORMIXOPCACHE Specifies the size of the memory cache for the staging-area blobspace of the client application INFORMIXSERVER Specifies the default database server to which an explicit or implicit connection is made by a client application.Discontinued: This property was discontinued in 4.10.JC4. If it is set, it is ignored. INFORMIXSERVER_SECONDARY Specifies the secondary database server in an HDR pair to which an explicit or implicit connection is made by a client application if the primary database server is unavailable. INFORMIXSTACKSIZE Specifies the stack size, in kilobytes, that the database server uses for a particular client session. JDBCTEMP Specifies where temporary files for handling smart large objects are created. You must supply an absolute path name. LOBCACHE Determines the buffer size for large object data that is fetched from the database server Possible values are: A number greater than 0 The maximum number of bytes is allocated in memory to hold the data. If the data size exceeds the LOBCACHE value, the data is stored in a temporary file; if a security violation occurs during creation of this file, the data is stored in memory. Zero The data is always stored in a file. If a security violation occurs, the driver makes no attempt to store the data in memory. A negative number The data is always stored in memory. If the required amount of memory is not available, an error occurs. If the LOBCACHE value is not specified, the default is 4096 bytes. LOGINTIMEOUT Determines whether the Informix database server is running. If the server is running a connection to the server is established immediately. If the server is not running, this environment variable specifies how long, in milliseconds, that the server port is polled to establish a connection. If your application does not connect to the Informix database server within the specified time, an error is returned. NEWNLSMAP Allows new mappings to be defined between NLS and Java development kit locales and code sets. For more information, see User-defined locales. NODEFDAC Prevents the PUBLIC group from receiving table or routine privileges by default when new tables or UDRs are created in a database that was not created WITH LOG MODE ANSI. The required yes setting is case sensitive. OPT_GOAL Specifies the query performance goal for the optimizer. Set this variable in the user environment before you start an application. The driver does not use this variable; it just passes the value to the server. OPTCOMPIND Specifies the join method that the query optimizer uses OPTOFC When set to 1, the ResultSet.close() method does not require a network round trip if all the qualifying rows have already been retrieved in the clients tuple buffer. The database server automatically closes the cursor after all the rows have been retrieved. IBM Informix JDBC Driver might not have additional rows in the clients tuple buffer before the next ResultSet.next() method is called. Therefore, unless IBM Informix JDBC Driver has received all the rows from the database server, the ResultSet.close() method might still require a network round trip when OPTOFC is set to 1. PATH Specifies the directories that are to be searched for executable programs PDQPRIORITY Determines the degree of parallelism used by the database server PLCONFIG Specifies the name of the configuration file used by the high-performance loader PLOAD_LO_PATH Specifies the path name for smart-large-object handles (which identify the location of smart large objects such as BLOB, CLOB, and BOOLEAN data types). The driver does not use this variable; it just passes the value to the server. PORTNO_SECONDARY Specifies the port number of the secondary database server in an HDR pair. The port number is listed in the /etc/services file. PROXY Specifies an HTTP proxy server. For more information, see An HTTP proxy server. PSORT_DBTEMP Specifies one or more directories to which the database server writes the temporary files it uses when performing a sort PSORT_NPROCS Enables the database server to improve the performance of the parallel-process sorting package by allocating more threads for sorting SECURITY Uses 56-bit encryption to send the password to the server. For more information, see Password encryption. SQLH_TYPE When set to FILE, specifies that database information (such as host-name, port-number, user, and password) is specified in an sqlhosts file. When set to LDAP, specifies that this information is specified in an LDAP server. For more information, see Dynamically reading the Informix sqlhosts file. SQLIDEBUG Specifies the path name for the file to which a binary SQLI trace is to be written. A new trace file is generated for every connection and is suffixed with timestamp. Only use the SQLI trace facility when directed by an IBM technical support representative. SRV_FET_BUF_SIZE Overrides the default setting for the size of the fetch buffer in distributed transactions with other database servers. That fetch buffer holds, for example, the data retrieved by a cross-server distributed query. For IBM Informix xC5 and later versions, the maximum value is (1MiB). STMT_CACHE When set to 1, enables the use of the shared-statement cache in a session. This feature can reduce memory consumption and speed query processing among different user sessions. The driver does not use this variable; it just passes the value to the server. TRUSTED_CONTEXT When set to TRUE, a trusted connection request is sent from client. Either a successful trusted connection is established or the following error is returned from the server: SQL Exception : (Trusted Connection request rejected.) © 2016 IBM Corporation 113

listener.hostName Wire Listener Parameter
Specifies the host name of the wire listener. The host name determines the network adapter or interface that the wire listener binds the server socket to. To enable the wire listener to be accessed by clients on remote hosts, turn on authentication by using the authentication.enable parameter. .--localhost--. >>-listener.hostName=--+-hostname >< '-* ' localhost Bind the wire listener to the localhost address. The wire listener is not accessible from clients on remote machines. Default value. hostname The host name or IP address of host machine where the wire listener binds to. * The wire listener can bind to all interfaces or addresses. © 2016 IBM Corporation

collection.informix.options Wire Listener Parameter (1)
Specifies table options for shadow columns or auditing to use when creating a JSON collection. .-, V | >>-collection.informix.options=[ ]----->< +-"audit" +-"crcols" +-"erkey" +-"replcheck"-+ '-"vercols"-----' © 2016 IBM Corporation

collection.informix.options Wire Listener Parameter (2)
audit Uses the CREATE TABLE statement AUDIT option to create a table to be included in the set of tables that are audited at the row level if selective row-level is enabled. crcols Uses the CREATE TABLE statement CRCOLS option to create the two shadow columns that Enterprise Replication uses for conflict resolution. erkey Uses the CREATE TABLE statement ERKEY option to create the ERKEY shadow columns that Enterprise Replication uses for a replication key. replcheck Uses the CREATE TABLE statement REPLCHECK option to create the ifx_replcheck shadow column that Enterprise Replication uses for consistency checking. vercols Uses the CREATE TABLE statement VERCOLS option to create two shadow columns that Informix uses to support update operations on secondary servers. © 2016 IBM Corporation 116

command.listDatabases.sizeStrategy (1)
Wire listener parameter specifying a strategy to calculate the size of your database when the MongoDB listDatabases command is run. The listDatabases command estimates the size of all collections and collection indexes for each database: Relational tables and indexes are excluded from this size calculation. Performs expensive and CPU-intensive computations on the size of each database in the database server instance. You can decrease the expense by using the new in xC5 command.listDatabases.sizeStrategy parameter. .---estimate >>-command.listDatabases.sizeStrategy=---+-{estimate:n} >< +-compute +-none '-perDatabaseSpace-' © 2016 IBM Corporation

estimate Estimate the database size by sampling documents in every collection; this is the default value. This strategy is the equivalent of {estimate: 1000}, which takes a sample size of 0.1% of the documents in every collection; this is the default value. command.listDatabases.sizeStrategy=estimate estimate: n Estimate the database size by sampling one document for every n documents in every collection. The following example estimates the collection size by using sample size of 0.5% or 1/200th of the documents: command.listDatabases.sizeStrategy={estimate:200} © 2016 IBM Corporation

compute Compute the exact size of the database. command.listDatabases.sizeStrategy=compute none List the databases but do not compute the size. The database size is listed as 0. command.listDatabases.sizeStrategy=none perDatabaseSpace Calculates the size of a tenant database created by multi-tenancy feature by adding the sizes for all dbspaces, sbspaces, and blobspaces that are assigned to the tenant database. © 2016 IBM Corporation

fragment.count Wire Listener Parameter
Specifies the number of fragments to use when creating a collection. The database server determines the number of collection fragments to create. Default. fragment_num > 0, Number of collection fragments created at collection creation. >>-fragment.count=--+-fragment_num >< © 2016 IBM Corporation

jdbc.afterNewConnectionCreation
Wire listener parameter specifies one or more SQL commands to run after a new connection to the database is created. .-, V | >>-jdbc.afterNewConnectionCreation=[---"sql_command"-+-] >< For example, to accelerate queries run through the wire listener by using the Informix Warehouse Accelerator: jdbc.afterNewConnectionCreation=["SET ENVIRONMENT USE_DWA 'ACCELERATE ON'"] © 2016 IBM Corporation

authentication.enable Wire Listener Parameter (1)
Specifies whether to enable user authentication. Authentication of MongoDB clients occurs in the wire listener, not in the database server. Privileges are enforced by the wire listener. All communications that are sent to the database server originate from the user that is specified in the url parameter, regardless of which user was authenticated. User information and privileges are stored in the system_users collection in each database. MongoDB authentication is done on a per database level, whereas Informix authenticates to the instance. © 2016 IBM Corporation

authentication.enable Wire Listener Parameter (2)
.-false-. >>-authentication.enable=--+-true >< false Do not authenticate users. This is the default value. True Authenticate users. Use the authentication.localhost.bypass.enable parameter to control the type of authentication. © 2016 IBM Corporation

Wire Listener Logging – Default Logback Mechanism (1)
The wire listener can output trace, debug, informational messages, warnings, and error information to a log. Logback is pre-configured and installed along with the JSON components. If you start the wire listener from the command line, you can specify the amount of detail, name, and location of your log file by using the -loglevel and -logfile command-line arguments. If you have customized the Logback configuration or specified another logging framework, the settings for -loglevel and -logfile are ignored. For more information on how to customize Logback, see © 2016 IBM Corporation 124

Wire Listener Logging – Default Logback Mechanism (2)
If the wire listener is started automatically after you create a server instance or if you run the task() or admin() function with the start json listener argument, errors are sent to a log file: UNIX: The log file is in $INFORMIXDIR/jsonListener.log. Windows: The log file is named servername_jsonListener.log and is in your home directory. C:\Users\ifxjson\ol_informix1210_5_jsonListener.log. © 2016 IBM Corporation

Enhanced Account Management Via the Wire Listener
Control user authorization to Informix databases through the wire listener by locking and unlocking user accounts or individual databases via the new Informix JSON lockAccount and unlockAccounts commands. © 2016 IBM Corporation

JSON – lockAccounts – Lock a Database/User Account
If you specify the lockAccounts:1 command without specifying a db or user argument, all accounts in all databases are locked. Run this command as instance administrator. Syntax: >>-lockAccounts:----1, >< +-db:-+-"database_name" “---+ | | .-, | | | | V | | | | [---"database_name"-+-] | | {"$regex":"json_document"} | | | .-, | | | | | V | | | | '-{---+-"include":-+-"database_name" }-' | | | | .-, | | | | | | V | | | | | | [---"database_name"-+-] | | | | '-{"$regex":"json_document"}---‘ | | | '-"exclude":-+-"database_name" ' | | | .-, | | | | V | | | | [---"database_name"-+-] | | '- {"$regex":"json_document"}-' | '-user:-+-"user_name" ' '-"json_document"-' © 2016 IBM Corporation

Required parameter locks a database or user account. db Optional parameter specifies the database name of an account to lock. For example, to lock all accounts in database that is named foo: db.runCommand({lockAccounts:1,db:"foo"}) exclude Optional parameter specifies the databases to exclude. For example, to lock all accounts on the system except those in the databases named alpha and beta: db.runCommand({lockAccounts:1,db:{"exclude":["alpha","beta"]}) © 2016 IBM Corporation

include Optional parameter specifies the databases to include. To lock all accounts in the databases named delta and gamma: db.runCommand({lockAccounts:1,db:{"include":["delta","gamma"]}) $regex Optional evaluation query operator selects values from a specified JSON document. To lock accounts for databases that begin with the character a. and end in e: db.runCommand({lockAccounts:1,db:{"$regex":"a.*e"}) user Optional parameter specifies the user accounts to lock. For example, to lock the account of all users that are not named alice: db.runCommand({lockAccounts:1,user:{$ne:"alice"}}); © 2016 IBM Corporation

JSON – unlockAccounts – Unlock a Database/User Account
If you specify the unlockAccounts:1 without specifying a db or user argument, all accounts in all databases are unlocked. Run this command as instance administrator. >>-unlockAccounts: , >< +-db:-+-"database_name" "-+ | | .-, | | | | V | | | | [---"database_name"-+-] | | {"$regex":"json_document"} | | | .-, | | | | V | | | | '-{---+-"include":-+-"database_name" }-' | | | | .-, | | | | | | V | | | | | | [---"database_name"-+-] | | | | '-{"$regex":"json_document"}----' | | | '-"exclude":-+-"database_name" ' | | | .-, | | | | V | | | | [---"database_name"-+-] | | '-{"$regex":"json_document"}-' | '-user:-+-"user_name" ' '-"json_document"-' © 2016 IBM Corporation

Required parameter unlocks a database or user account. db Optional parameter specifies the database name of an account to unlock. To unlock all accounts in database that is named foo: db.runCommand({unlockAccounts:1,db:"foo"}) exclude Optional parameter specifies the databases to exclude. To unlock all accounts on the system except those in the databases named alpha and beta: db.runCommand({unlockAccounts:1,db:{"exclude":["alpha","beta"]}) © 2016 IBM Corporation

include Optional parameter specifies the databases to include. To unlock all accounts in the databases named delta and gamma: db.runCommand({unlockAccounts:1,db:{"include":["delta","gamma"]}) $regex Optional evaluation query operator selects values from a specified JSON document. To unlock accounts for databases that begin with the character a. and end in e: db.runCommand({unlockAccounts:1,db:{"$regex":"a.*e"}) user This optional parameter specifies the user accounts to unlock. For example, to unlock the account of all users that are not named alice: db.runCommand({unlockAccounts:1,user:{$ne:"alice"}}); © 2016 IBM Corporation

Manipulation of JSON & BSON Data Types with SQL
JSON and BSON data types, allowed in local and distributed queries, are Informix built-in data types accessible and manipulatible with SQL statements. By calling BSON value functions within SQL statements it is possible to retrieve specific key values from JSON or BSON data columns. It is possible to define indexes on key values within a JSON or BSON column. © 2016 IBM Corporation

High Availability for MongoDB and REST Clients
MongoDB and REST clients can be provided High Availability functionality via running a wire listener on each server in an Informix high-availability cluster. Provide high availability between the wire listener and the Informix database server: Connect the wire listener to the database server through the Connection Manager Specify an sqlhosts file via the url parameter in the wire listener properties file. © 2016 IBM Corporation

Wire Listener Configuration Enhancements
These new or updated parameters can be set in the wire listener properties file: url parameter can include JDBC environment variables. listener.hostName parameter can specify the listener host name to control the network adapter or interface to which the wire listener connects. collection.informix.options parameter specifies table options to automatically add shadow columns or enable auditing during JSON collection creation. command.listDatabases.sizeStrategy parameter can specify a strategy for computing the database size when listDatabases is executed. fragment.count parameter can specify the number of fragments to create for a collection. jdbc.afterNewConnectionCreation parameter can specify SQL statements, such as SET ENVIRONMENT, to run after connecting to the database server. © 2016 IBM Corporation

Wire Listener Query Support
The wire listener now supports these types of queries: Join queries on; JSON data Relational data or Both JSON and relational data. Array queries on JSON data with the $elemMatch query operator: Ratings, for example, must be an arrayed column in the inventory collection. db.inventory.find( { ratings: { $elemMatch: { $gt: 25, $lt: 90 } } } ) $first and $last group operators © 2016 IBM Corporation

Wire Listener Query Support (1)
Join query support is an important part of the hybrid SQL/NoSQL value proposition of Informix. The JSON listener now supports the following running joins by querying against a new pseudo system.join table: Collection-to-collection Relational-to-relational Collection-to-relational Join queries are done by running a “find” query against the new pseudo system table called system.join. For, example, in the Mongo shell, you’d run a query like this: > db.system.join.find( { join query document } ) © 2016 IBM Corporation

Join Query Document: { $collections : { “tabName1” : { join_table_specification }, “tabName2” : { join_table_specification }, … }, “$condition” : { join_condition_specification } } Required: $collections and $condition fields to run a find query against system.join. The $collections field must map to a document that includes two or more collections or relational tables to be joined. The $condition specifies how to join the collections/tables. No other query operators are supported in the top level of the join query document. (over) © 2016 IBM Corporation 138

The join_table_specification for each collection/table must include the required $project field; can have an optional $where query document: {“$project” : { … }, “$where”: { … }} The $project field follows the same projection syntax as regular Mongo queries. The optional $where field and uses the same query syntax as regular Mongo queries. The join_condition_specification is a document of key-value pairs that define how all of the tables specified are joined together. These conditions can be specified in two ways: A key-string value pair to map a single table’s column to another table’s column: “tabName1.column1”: “tabName2.column2” As a key-array pair to map a table’s column to multiple other table columns. “tabName1.column1”: [ “tabName2.column2”, “tabName3.column3”, …. ] © 2016 IBM Corporation

Wire Listener Query Support – Implementation Details
Join queries work: With the sort, limit, skip, and explain options that can be set on a Mongo cursor With listener cursoring Collection-to-Collection joins: The listener will look up if there are matching typed BSON indexes on the join fields for each collection. If so, it will use that bson_value_* function in the join condition to take advantage of the index. If the join was on customer.customer_num and orders.customers_num and there were bson_value_int indexes on both customer.customer_num and orders.customer_num, then the listener SQL join condition would be: bson_value_int(customer.data, “customer_num”) = bson_value_int(orders.data, “customer_num”) © 2016 IBM Corporation

Wire Listener Query Support – Implementation Details
If there are no matching indexes using the same bson_value_* function, then the listener defaults to the bson_get function for the join condition: bson_get(customer.data, “customer_num”) = bson_get(orders.data, “customer_num”) Collection-to-Relational joins: For collection-to-relational joins, the data type of the relational column determines the bson_value_* function that is used: If joining a collection field to a character relational column, the bson_value_lvarchar function is used. If joining a collection field to a numeric relational column, the bson_value_double function is used, etc. Relational-to-Relational joins: No type conversions in the SQL query itself are necessary. The SQL condition is as expected: tab1.col1 = tab2.col2 © 2016 IBM Corporation

Wire Listener Query Support Examples (1)
For all these examples, the tables can be collections, relational tables, or a combination of both; the syntax is the same. Example 1: Get the customers orders that totaled more than $100. Join the customers and orders collections/tables on the customer_num field/column where the order total > 100. { “$collections” : { “customers” : { “$project”: { customer_num: 1, name: 1, phone: 1 } }, “orders” : { “$project”: { order_num: 1, nitems: 1, total: 1, _id: 0 }, “$where” : { total : { “$gt”: 100 } } } }, “$condition” : { “customers.customer_num” : “orders.customer_num” } } © 2016 IBM Corporation

Get the IBM locations in California and Oregon. Join the companies, sites, and zipcodes collections/tables where company name is “IBM” and state is “CA” or “OR”. { $collections : { “companies” : { “$project”: { name: 1, _id: 0 } “$where” : { “name” : “IBM” } }, “sites” : { “$project”: { site_name: 1, size: 1, zipcode: 1, _id:0 } }, “zipcodes” : { “$project”: { state: 1, city: 1, _id:0 } “$where” : { “state”: { “$in”, [“CA”, “OR”] } } } }, “$condition” : { “companies._id” : “sites.company_id”, “sites.zipcode” : “zipcodes.zipcode” } } © 2016 IBM Corporation

Use array syntax in the condition. Get the order info, shipment info, and payment info for order number 1093. { $collections : { “orders” : { “$project”: { order_num: 1, nitems: 1, total: 1, _id: 0 }, “$where” : { order_num : 1093 } }, “shipments” : { “$project”: { shipment_date: 1, arrival_date: 1 } }, “payments” : { “$project”: { payment_method: 1, payment_date: 1 } } }, “$condition” : { “orders.order_num” : [ “shipments.order_num”, “payments.order_num” ] } © 2016 IBM Corporation

Agenda – Informix Warehouse Accelerator (IWA)
Queries with the following SQL structures can be accelerated: SQRT scalar function queries to calculate square roots UNITS MONTH UNITS YEAR CURRENT DATETIME YEAR TO MONTH View information about existing data marts in the accelerators by running the ondwa listmarts command. Load data marts faster by adding a second DWAVP virtual processor. © 2016 IBM Corporation

SQRT Function Accelerated.
A picture is worth 10,000 words: © 2016 IBM Corporation

UNITS MONTH and UNITS YEAR
Queries in the following form involving the UNITS MONTH and UNITS YEAR keywords can be accelerated via Informix Warehouse Accelerator: Example for UNITS YEAR and UNITS MONTH: create table dwa.t1 (c0 serial, c1 integer, c2 date); select c0 from t1 where c1 = year(today - 1 units MONTH ); select c0,c1,(today - c2) from t1 where c1 = year(today - c2 - 1 units YEAR ); © 2016 IBM Corporation

UNITS MONTH (1) QUERY: DWA executed:(OPTIMIZATION TIMESTAMP: :56:20) ------ select c0 from t1 where c1 = year(today - 1 units MONTH ) Estimated Cost: 2 Estimated # of Rows Returned: 1 1) DWA REMOTE PATH Remote SQL Request: {QUERY {FROM informix.aqt45a9384f-94a2-4dcd-95db a5} {WHERE {= COL3 {YEAR {- {DATE "819 03/02/2015"} {DURATION_MONTH 1} } } } } {SELECT {SYSCAST COL2 AS INTEGER} } } © 2016 IBM Corporation

UNITS MONTH (2) QUERY: IDS FYI:(OPTIMIZATION TIMESTAMP: :56:20) ------ select c0 from t1 where c1 = year(today - 1 units MONTH ) Estimated Cost: 2 Estimated # of Rows Returned: 1 1) informix.t1: SEQUENTIAL SCAN Filters: informix.t1.c1 = YEAR (TODAY - interval( 1) month(9) to month ) Query statistics: Table map : Internal name Table name type rows_prod est_rows time est_cost dwa : © 2016 IBM Corporation

UNITS YEAR (1) QUERY: DWA executed:(OPTIMIZATION TIMESTAMP: :56:20) ------ select c0,c1,(today - c2) from t1 where c1 = year(today - c2 - 1 units YEAR ) Estimated Cost: 2 Estimated # of Rows Returned: 1 1) DWA REMOTE PATH Remote SQL Request: {QUERY {FROM informix.aqt45a9384f-94a2-4dcd-95db a5} {WHERE {= COL3 {YEAR {- {- {DATE "819 03/02/2015"} COL4 } {DURATION_YEAR 1} } } } } {SELECT {SYSCAST COL2 AS INTEGER} {SYSCAST COL3 AS INTEGER} {SYSCAST {- {DATE "819 03/02/2015"} COL4 } AS I NTEGER} } } © 2016 IBM Corporation

CURRENT Queries in the following form involving the CURRENT keyword can be accelerated via Informix Warehouse Accelerator: create table dwa.t1 (c0 serial, c1 datetime year to fraction(3)); select * from t1 where c1 <= CURRENT; select * from t1 where c1 <= CURRENT year to hour; select * from t1 where c1::datetime hour to second <= CURRENT hour to second; © 2016 IBM Corporation

CURRENT (1) QUERY: DWA executed:(OPTIMIZATION TIMESTAMP: :04:27) ------ select * from t1 where c1 <= CURRENT Estimated Cost: 2 Estimated # of Rows Returned: 1 1) DWA REMOTE PATH Remote SQL Request: {QUERY {FROM informix.aqtd5798a57-b92e-4d94-b52e-957f4c7a4034} {WHERE {<= COL3 {TIMESTAMP " :04: "} } } {SELECT {SYSCAST COL2 AS INTEGER} {SYSCAST COL3 AS TIMESTAMP } } } © 2016 IBM Corporation

CURRENT (2) QUERY: IDS FYI:(OPTIMIZATION TIMESTAMP: :04:27) ------ select * from t1 where c1 <= CURRENT Estimated Cost: 2 Estimated # of Rows Returned: 1 1) informix.t1: SEQUENTIAL SCAN Filters: informix.t1.c1 <= CURRENT year to fraction(3) Query statistics: Table map : Internal name Table name type rows_prod est_rows time est_cost dwa : © 2016 IBM Corporation 154

CURRENT year to hour (1) QUERY: DWA executed:(OPTIMIZATION TIMESTAMP: :04:27) ------ select * from t1 where c1 <= CURRENT YEAR TO HOUR Estimated Cost: 2 Estimated # of Rows Returned: 1 1) DWA REMOTE PATH Remote SQL Request: {QUERY {FROM informix.aqtd5798a57-b92e-4d94-b52e-957f4c7a4034} {WHERE {<= COL3 {TIMESTAMP " :00: "} } } {SELECT {SYSCAST COL2 AS INTEGER} {SYSCAST COL3 AS TIMESTAMP } } } © 2016 IBM Corporation

CURRENT year to hour (2) QUERY: IDS FYI:(OPTIMIZATION TIMESTAMP: :04:27) ------ select * from t1 where c1 <= CURRENT YEAR TO HOUR Estimated Cost: 2 Estimated # of Rows Returned: 1 1) informix.t1: SEQUENTIAL SCAN Filters: informix.t1.c1 <= CURRENT year to hour Query statistics: Table map : Internal name Table name type rows_prod est_rows time est_cost dwa : © 2016 IBM Corporation

CURRENT hour to second (1)
QUERY: DWA executed:(OPTIMIZATION TIMESTAMP: :04:27) ------ select * from t1 where c1::datetime hour to second <= CURRENT hour to second Estimated Cost: 2 Estimated # of Rows Returned: 1 1) DWA REMOTE PATH Remote SQL Request: {QUERY {FROM informix.aqtd5798a57-b92e-4d94-b52e-957f4c7a4034} {WHERE {<= {CAST COL3 AS TIME } {TIME "819 18:04:27"} } } {SELECT {SYSCAST COL2 AS INTEGER} {SYSCAST COL3 AS TIMESTAMP } } } © 2016 IBM Corporation

CURRENT hour to second (2)
QUERY: IDS FYI:(OPTIMIZATION TIMESTAMP: :04:27) ------ select * from t1 where c1::datetime hour to second <= CURRENT hour to second Estimated Cost: 2 Estimated # of Rows Returned: 1 1) informix.t1: SEQUENTIAL SCAN Filters: informix.t1.c1 ::datetime hour to second<= CURRENT hour to second Query statistics: Table map : Internal name Table name type rows_prod est_rows time est_cost dwa : © 2016 IBM Corporation

CURRENT year to month (1)
QUERY: DWA attempted:(OPTIMIZATION TIMESTAMP: :25:20) ------ select * from t1 where c1 <= CURRENT YEAR TO MONTH Estimated Cost: 2 Estimated # of Rows Returned: 1 1) DWA REMOTE PATH Remote SQL Request: {QUERY {FROM informix.aqte ba9-410b-a972-b3e3962bc4df} {WHERE {<= COL3 {DATE " "} } } {SELECT {SYSCAST COL2 AS INTEGER} {SYSCAST COL3 AS TIMESTAMP } } } © 2016 IBM Corporation

CURRENT year to month (2)
QUERY: IDS executed:(OPTIMIZATION TIMESTAMP: :25:20) ------ select * from t1 where c1 <= CURRENT YEAR TO MONTH Estimated Cost: 2 Estimated # of Rows Returned: 1 1) informix.t1: SEQUENTIAL SCAN Filters: informix.t1.c1 <= CURRENT year to month Query statistics: Table map : Internal name Table name t t1 type table rows_prod est_rows rows_scan time est_cost scan t : © 2016 IBM Corporation

UNITS YEAR(2) QUERY: IDS FYI:(OPTIMIZATION TIMESTAMP: :56:20) ------ select c0,c1,(today - c2) from t1 where c1 = year(today - c2 - 1 units YEAR ) Estimated Cost: 2 Estimated # of Rows Returned: 1 1) informix.t1: SEQUENTIAL SCAN Filters: informix.t1.c1 = YEAR (TODAY - informix.t1.c2 - interval( ) year(9) to year ) Query statistics: Table map : Internal name Table name type rows_prod est_rows time est_cost dwa : © 2016 IBM Corporation

ondwa listmarts View information about existing data marts in the accelerators by running the ondwa listmarts command. Data shown below is as follows: Mart Name Mart Id Accelerator Name State – Active or, Load Pending Epoch – Number representing the version of the mart since creation. © 2016 IBM Corporation

Multiple DWAVP’s for Loading Performance
When initialized, IWA automatically creates a single Virtual Processor (VP) dedicated to its operations when the first IWA related activity occurs and there is no IWA VP definition in the configuration file. This IWA VP is known internally by name as a dwavp. The dwavp is permanently and explicitly created by the DBA at the time of initialization in the configuration file: VPCLASS dwavp,num=1 If not explicitly added, a single dwavp virtual processor is allocated dynamically when the first IWA related activity occurs. To add a dwavp virtual processor for the database server instance from the command line: onmode -p +1 dwavp © 2016 IBM Corporation

Multiple DWAVP’s for Loading Performance
When loading multiple data marts, you can define two dwavp virtual processors to avoid administrative command delays while loading data marts. For example, to add two dwavp virtual processors for the database server instance, in the $ONCONFIG file: VPCLASS dwavp,num=2. © 2016 IBM Corporation

Devices, Platforms & Environments
Raspberry PI devices certified for V6 ARM 32 with IDS 12. IDS Developer Edition 12 for ARM V7 32 INTEL Quark (DK50) 32 bit and IDS 12 Smaller runtime embed footprint using revised onconfig settings for devices. Mac OS 10.9 client/server support for Mac-based device developers New xC5 Platforms : Mac OS X 10.8, 10.9 ARM v7 Quark Raspberry Pi Ubuntu 64-bit for ARM v8 (64-bit) RHEL 7 certification for Linux x86-64 (64-bit) PPC64 © 2016 IBM Corporation

Miscellaneous Tivoli Work Manager 9.3 Support for Informix 12.
Clear text passwords no longer passed by onstat –g ses/sql Simple REST API deployed CSDK - Improved UTF-8 support in the ODBC Driver. Advanced Enterprise Edition Server binaries are now stamped Advanced Enterprise with applicable license. Improved Guardium 10 support for Informix (Q3 2015). No details available at this time for these items, other than they are complete at this time. There will be further items as they are completed. Its crunch time. © 2016 IBM Corporation 166

Agenda Point-in-Time Restores via On-Bar Parallel Instance Restore
Limit Tenant Database Shared Memory Limit Tenant Database Connections Parallelized Sharded Queries Wire Listener Configuration File Enhancements Increase Throughput for Cluster Communications MongoDB 2.6 and 3.0 Compatibility Faster index transfer to secondary servers Easier cloning of database servers - ifxclone JDBC Enhancements Guardium V10 Support IWA Enhancement New Platforms © 2016 IBM Corporation

Point in Time Restores of Tenant Database via OnBar
Prerequisites: The tenant database storage spaces must have a physical backup. The database server must be online. Tenant definition storages spaces must exist. Tenant storage spaces must have unique names for existing backups. If a tenant database having backups is dropped and storage spaces with the same names used in a new tenant database, the backups of the dropped tenant database must be removed. No other warm or tenant restores are running. HA Cluster prerequisites: Read only HDR secondaries and RSS secondaries. SDS or updatable secondary servers not allowed. All secondary servers must be online. © 2016 IBM Corporation

HA Cluster prerequisites (cont’d): Run only on the primary server: During the restore, internally generated commands are run on the secondary servers to restore the new state of the tenant database spaces on the secondaries. Includes new tenant space physical backups in their new state. Command does not return until all secondary servers acknowledge the completion of the automatically generated restores of the new tenant space backups. Logical logs required for the tenant database restore are restored to the temporary spaces in the DBSPACETEMP configuration parameter. If the DBSPACETEMP configuration parameter is not set, temporary files are created in the root dbspace. To restore a tenant database to a point in time: onbar -r -T tenant_database -t "time" -O Substitute tenant_database with the name of the tenant database. Substitute time with the time of the last transaction to be restored from the logical logs. Time is datetime year to second Omission of the -O option requires all the permanent tenant spaces must be marked as down before you run the restore command. Temporary spaces are never backed up or restored. © 2016 IBM Corporation

Operational notes: If the restore fails, fix the problem and run the restore again. Tenant database are blocked from accepting connections until the restore succeeds. During the restore, the value of the tenant_state field is set to restoring in the tenant_resources column of the sysadmin:tenant table. When a tenant database is blocked, the value of the tenant_state field is set to blocked. How to see the value of the tenant_state field: SELECT bson_value_lvarchar(tenant_resources, 'tenant_state') AS tenant_state FROM sysadmin:tenant WHERE tenant_dbsname = 'tenant_dbname'; Substitute tenant_dbname with the name of the tenant database. Example: Point In Time restore of a tenant database named tom : onbar -r -T tom -t " :00:57" -O © 2016 IBM Corporation

Instance Restore Parallelism – BAR_MAX_RESTORE
You can set the number of parallel processes to run during a restore independently from the number of processes for a backup with the new BAR_MAX_RESTORE configuration parameter. Previously, the BAR_MAX_BACKUP configuration parameter controlled the number of processes for both backups and restores. © 2016 IBM Corporation

The Unix and Windows On-Bar BAR_MAX_RESTORE onconfig parameter specifies a max number of parallel restore processes allowed in a restore operation. onconfig.std value 0 If the value is not present, the value of BAR_MAX_BACKUP is used The value is the number of ON-Bar processes: 0 = Maximum number of restore processes allowed on system 1 = Serial restore n = Specified number of restore processes created Takes effect: When ON-Bar starts Dynamically in your onconfig file via onmode -wf or equivalent SQL administration API command. © 2016 IBM Corporation

Specify serial restores Including a serial whole system restore, set BAR_MAX_RESTORE to 1. Specify parallel restores Including parallel whole system restores, set BAR_MAX_RESTORE > 1. If BAR_MAX_RESTORE = 5 and you start a restore, the maximum number of restore processes that ON-Bar creates concurrently is 5. Configure BAR_MAX_RESTORE to any number up to the maximum number of storage devices or the maximum number of streams available for physical restores. ON-Bar groups the dbspaces by size for efficient use of parallel resources. If BAR_MAX_RESTORE = 0, the system creates as many ON-Bar restore processes as needed: This number is limited only by the number of storage spaces or the amount of memory available to the database server, whichever is less. © 2016 IBM Corporation

The amount of memory available is based on SHMTOTAL. ON-Bar performs the following calculation where N is the maximum number of ON-Bar processes that are allowed: N = SHMTOTAL / (# transport buffers * size of transport buffers / 1024) If SHMTOTAL is 0, BAR_MAX_RESTORE is reset to 1. If N is greater than BAR_MAX_RESTORE, ON-Bar uses the BAR_MAX_RESTORE value. Otherwise, ON-Bar starts N restore processes. © 2016 IBM Corporation

Limit Tenant Database Shared Memory & Connections
You can limit shared memory and the number of connections for tenant databases in a multitenancy environment. You can use configuration parameters to set limits for all tenants or parameters to the tenant create or tenant update argument to the task or admin SQL administration API command: Set the TENANT_LIMIT_MEMORY configuration parameter or include the tenant_limit_memory parameter of the SQL Admin API to limit the shared memory for all sessions connected to the tenant database. When the limit is exceeded, the session that is using the most shared memory is terminated. Set the TENANT_LIMIT_CONNECTIONS configuration parameter or include the tenant_limit_connections parameter of the SQL Admin API to limit the number of client connections to a tenant database. When the limit is reached, subsequent connection requests to the tenant database are rejected. © 2016 IBM Corporation

Limit Tenant Database Connections
The TENANT_LIMIT_CONNECTIONS configuration parameter specifies the maximum number of connections to a tenant database. onconfig.std value 0 (off) If not present 0 (off) Values Takes effect after you edit your onconfig file and restart the database server. Usage When the limit is reached, subsequent connection requests to the tenant database are rejected. © 2016 IBM Corporation

Limit Tenant Connection Memory
The TENANT_LIMIT_MEMORY configuration parameter specifies the max amount of shared memory for all sessions connected to the tenant database. onconfig.std value 0 (off) If not present 0 (off) Values Units KB Takes effect After you edit your onconfig file and restart the database server. Usage When the limit is exceeded, the session using the most shared memory is terminated. The value ranges from 100 MB to 2 TB; an integer specified in KB. Precedence: The tenant_limit_memory tenant database property set through the tenant create or tenant update SQL Admin API has precedence over the TENANT_LIMIT_MEMORY configuration parameter setting. © 2016 IBM Corporation

Parallelized Sharded Queries
Run SELECT statements in sharded queries in parallel instead of serially on each shard Parallel sharded queries return results faster Reduced memory consumption: Table consistency is enforced on the shard servers, which eliminates the processing of data dictionary information among the shard servers. Reduced network traffic: Client connections are multiplexed over a common pipe instead of being created individual connections between each client and every shard server. Client connections are authenticated on only one shard server instead of on every shard server. Network traffic to check table consistency is eliminated. © 2016 IBM Corporation

Parallelized Sharded Queries
To enable parallel sharded queries, set the new SHARD_ID configuration parameter in the onconfig file to a unique value on each shard server in the shard cluster. If upgrading your existing older 12.1 shard cluster, upgrade and set SHARD_ID on all the shard servers to enable parallel sharded queries. Run cdr define shardCollection Set the new sharding.parallel.query.enable=true and sharding.enable=true parameters in the wire listener configuration file for each shard server. Customize shared memory allocation for parallel sharded queries on each shard server by setting the new SHARD_MEM configuration parameter. Reduce latency between shard servers by increasing the number of pipes for SMX connections with the new SMX_NUMPIPES configuration parameter. © 2016 IBM Corporation

SHARD_ID Sets the unique ID for a shard server in a shard cluster.
onconfig.std value 0 Range of values 0 = Default. The database server cannot run parallel sharded queries. = The unique ID of the shard server. Takes effect After you edit your onconfig file and restart the database server If the value is 0 or not set, the value is dynamic via the onmode -wf command If the value is set > 0, you must edit the parameter and restart the database server Must be a unique number for each shard server in a shard cluster. If the value is unset or set to 0 on all shard servers in the shard cluster, the shard cluster performs poorly. If the values of the SHARD_ID configuration parameter are not unique on all shard servers in a shard cluster, shard queries fail. © 2016 IBM Corporation

New Wire Listener Configuration File Parameters
Set sharding.parallel.query.enable=true and sharding.enable=true for each shard server. sharding.parallel.query.enable Indicates whether to enable parallel sharded queries usage. Parallel sharded queries require that the SHARD_ID onconfig parameter be set to unique IDs on all shard servers. sharding.enable in the wire listener configuration file must also be set to true. .-false--. >>-sharding.parallel.query.enable=--+-true >< sharding.enable Enable/disable the use of commands and queries on sharded data. .-false-. >>-sharding.enable=--+-true >< false – Default. Disable the use of commands and queries on sharded data. true - Enable the use of commands and queries on sharded data. © 2016 IBM Corporation

SHARD_MEM – configuration parameter (1)
Allocation of shared memory for sharded queries on a shard server. onconfig.std value SHARD_MEM 0 range of values 0: Memory allocation for sharded queries comes from a single memory pool. 1: Memory allocation pools are associated with specific CPU VP’s. Enterprise Replication allocates memory to the CPU VP’s based on which CPU VP the parallel shard query thread is running on. 2: Memory allocation pools are associated with specific block sizes, so that all pool allocations are the same size, and the first free block that is found can be used. takes effect: After you edit your onconfig file and restart the database server. When you reset the value dynamically in your onconfig file by running the onmode -wf command. When you reset the value in memory by running the onmode -wm command. © 2016 IBM Corporation

SHARD_MEM – configuration parameter (2)
Usage SHARD_MEM 0 Is the traditional method of memory-allocation. Use this setting when resource allocation is more important than performance. SHARD_MEM 1 Prevents multiple threads from simultaneously accessing a memory pool. The performance of large-scale sharding environments can improve because memory allocation is done by multiple threads that are working in parallel. SHARD_MEM 2 Improves performance at the cost of increased memory usage. Memory allocation requests are increased to the closest fixed-block size, so that free memory blocks can be found faster. Memory pools are not associated with specific CPU VP’s, so memory can be freed directly to the memory pool. © 2016 IBM Corporation

SMX_NUMPIPES Configuration Parameter
Sets the number of pipes for server multiplexer group (SMX) connections. onconfig.std value SMX_NUMPIPES 1 values = The number of network pipes for SMX connections. takes effect After you edit your onconfig file and restart the database server. When you reset the value dynamically in your onconfig file by running the onmode -wf command. When you reset the value in memory by running the onmode -wm command. Usage High-availability clusters and parallel sharded queries use SMX connections. If the lag time between servers is too long, increase the number of SMX pipes. © 2016 IBM Corporation

SMX Connection Monitoring - onstat -g smx
You can use the onstat utility or system-monitoring interface (SMI) tables to view SMX connection statistics or SMX session statistics. To view SMX connection statistics, use the onstat -g smx command. To view SMX session statistics, use the onstat -g smx ses command. © 2016 IBM Corporation

onstat –g smx $ onstat –g smx SMX connection statistics:
SMX control block: 0x47d5e028 Peer server name: lx1 SMX connection address: 0x47d60d10 Encryption status: Disabled Total bytes sent: 27055 Total bytes received: Total buffers sent: 782 Total buffers received: 7090 Total write calls: 782 Total read calls: 7090 Total retries for write call: 0 Data compression level: 1 Data sent: compressed bytes by 33% Data received: compressed bytes by 84% © 2016 IBM Corporation

onstat –g smx (con’td) Output description SMX control block
Peer server name Displays the name of the peer server SMX connection address Displays the address of the SMX connection Encryption status Displays whether encryption is enabled or disabled Total bytes sent Displays the total number of bytes sent Total bytes received Displays the total number of bytes received Total buffers sent Displays the total number of buffers sent Total buffers received Displays the total number of buffers received Total write calls Displays the total number of write calls © 2016 IBM Corporation

onstat –g smx (con’td) Output description (con’td)
Total retries for write call Displays the total number of retries for write call Data compression level Displays the SMX compression level as set by the SMX_COMPRESS configuration parameter Data sent: compressed x bytes by y% Displays the uncompressed number of bytes and the compression ratio of the data sent Data received: compressed x bytes by y% Displays the uncompressed number of bytes and the compression ratio of the data received © 2016 IBM Corporation

onstat –g smx ses onstat -g smx ses Output Description
SMX control block SMX control block Peer name Displays the name of the peer server SMX session address SMX session address client type Displays type of secondary server reads Displays the total number of session reads writes Displays the total number of session writes © 2016 IBM Corporation

MongoDB 2.6 and 3.0 Compatibility – Informix Support
The following database management commands: Query and write insert, update, and delete. Instance administration createIndexes, listCollections, and listIndexes. User management, for MongoDB 2.6 and later, createUser, updateUser, dropUser, dropAllUserFromDatabase, grantRolesToUser, revokeRolesFromUser, and usersInfo. Role management: createRole, updateRole, dropRole, dropAllRolesFromDatabase, grantPrivilegesToRole, revokePrivilegesFromRole, grantRolesToRole, revokeRolesFromRole, and rolesInfo. Query and projection command: $eq. The field update operators: $mul, $min, $max, and $currentDate. The pipeline aggregation operator: $out. © 2016 IBM Corporation

MongoDB 2.6 and 3.0 Compatibility – Informix Support
You can authenticate MongoDB clients with the MongoDB 3.0 SCRAM-SHA-1 authentication method. You must upgrade the user schema for existing users. You upgrade to MongoDB 3.0 by setting the new mongo.api.version parameter to 3.0 in the wire listener configuration file. © 2016 IBM Corporation

Wire Listener Enhancements – New Parameters
MongoDB compatibility Specify the version of MongoDB API compatibility with the mongo.api.version. Security Disable commands with the command.blacklist. Specify the authentication type with the db.authentication. Specify an IP address as the administrative host with listener.admin.ipAddress. Set authentication timeout with the listener.authentication.timeout. Add information to HTTP headers with the listener.http.headers. Resource management Configure a memory monitor to reduce resource usage with listener.memoryMonitor. Create a separate thread pool for administrative connections with listener.pool.admin.enable Specify the timeout periods for socket connections with the listener.socket.accept.timeout and listener.socket.read.timeout Suppress pooled connection checking with pool.lenient.return.enable and pool.lenient.dispose.enable Specify the number of maintenance threads for connection pools with pool.service.threads. The wire listener configuration file The settings that control the wire listener and the connection between the client and database server are set in the wire listener configuration file. The default name for the configuration file is $INFORMIXDIR/etc/jsonListener.properties. You can rename this file, but the suffix must be .properties. If you create a server instance during the installation process, a configuration file that is named jsonListener.properties is automatically created with default properties, otherwise you must manually create the configuration file. You can use the $INFORMIXDIR/etc/jsonListener-example.properties file as a template. In the configuration file that is created during installation, and in the template file, all of the parameters are commented out by default. To enable a parameter, you must uncomment the row and customize the parameter. Important: The url parameter is required. All other parameters are optional. Required url Setup and configuration documentIdAlgorithm include listener.onException listener.hostName listener.port listener.type response.documents.count.default response.documents.count.maximum response.documents.size.maximum sharding.enable sharding.parallel.query.enable Command and operation configuration collection.informix.options command.listDatabases.sizeStrategy update.client.strategy update.mode Database resource management database.buffer.enable database.create.enable database.dbspace database.locale.default database.log.enable database.share.close.enable database.share.enable dbspace.strategy fragment.count jdbc.afterNewConnectionCreation MongoDB compatibility compatible.maxBsonObjectSize.enable mongo.api.version update.one.enable Performance delete.preparedStatement.cache.enable insert.batch.enable insert.batch.queue.enable insert.batch.queue.flush.interval index.cache.enable index.cache.update.interval insert.preparedStatement.cache.enable preparedStatement.cache.enable preparedStatement.cache.size Security authentication.enable authentication.localhost.bypass.enable command.blacklist db.authentication listener.admin.ipAddress listener.authentication.timeout listener.http.accessControlAllowCredentials listener.http.accessControlAllowHeaders listener.http.accessControlAllowMethods listener.http.accessControlAllowOrigin listener.http.accessControlExposeHeaders listener.http.accessControlMaxAge listener.http.headers listener.rest.cookie.domain listener.rest.cookie.httpOnly listener.rest.cookie.length listener.rest.cookie.name listener.rest.cookie.path listener.rest.cookie.secure listener.ssl.algorithm listener.ssl.ciphers listener.ssl.enable listener.ssl.key.alias listener.ssl.key.password listener.ssl.keyStore.file listener.ssl.keyStore.password listener.ssl.keyStore.type listener.ssl.protocol security.sql.passthrough Wire listener resource management listener.idle.timeout listener.input.buffer.size listener.memoryMonitor.enable listener.memoryMonitor.allPoint listener.memoryMonitor.diagnosticPoint listener.memoryMonitor.zeroPoint listener.output.buffer.size listener.pool.admin.enable listener.pool.keepAliveTime listener.pool.queue.size listener.pool.size.core listener.pool.size.maximum listener.socket.accept.timeout listener.socket.read.timeout pool.connections.maximum pool.idle.timeout pool.idle.timeunit pool.lenient.return.enable pool.lenient.dispose.enable pool.semaphore.timeout pool.semaphore.timeunit pool.service.interval pool.service.threads pool.service.timeunit pool.size.initial pool.size.minimum pool.size.maximum pool.type pool.typeMap.strategy response.documents.size.minimum Required parameter You must configure the url parameter before using the wire listener.url This required parameter specifies the host name, database server, user ID, and password that are used in connections to the database server. You must specify the sysmaster database in the url parameter. That database is used for administrative purposes by the wire listener. >>-url=--jdbc:informix-sqli://hostname:portnum--/sysmaster:-----> > >< '-USER=userid;--PASSWORD=password--NONCE=value-' You can include additional JDBC properties in the url parameter such as INFORMIXCONTIME, INFORMIXCONRETRY, LOGINTIMEOUT, and IFX_SOC_TIMEOUT. For a list of Informix® environment variables that are supported by the JDBC driver, see Informix environment variables with the IBM® Informix JDBC Driver. hostname:portnum The host name and port number of your computer. For example, localhost:9090. USER=userid This optional attribute specifies the user ID that is used in connections to the Informix database server. If you plan to use this connection to establish or modify collection shards by using the Informix sharding capability, the specified user must be granted the REPLICATION privilege group access. If you do not specify the user ID and password, the JDBC driver uses operating system authentication and all wire listener actions are run by using the user ID and password of the operating system user who runs the wire listener start command. PASSWORD=password This optional attribute specifies the password for the specified user ID. NONCE=value This optional attribute specifies a 16-character value that consists of numbers and the letters a, b, c, d, e, and f. This property triggers password encoding when a pluggable authentication module is configured for the wire listener. Applicable only if the db.authentication parameter is set to informix-mongodb-cr. These parameters provide setup and configuration options. documentIdAlgorithm This optional parameter determines the algorithm that is used to generate the unique Informix identifier for the ID column that is the primary key on the collection table. The _id field of the document is used as the input to the algorithm. The default value is documentIdAlgorithm=ObjectId. .-ObjectId-. >>-documentIdAlgorithm=--+-SHA >< +-SHA '-SHA-512--' ObjectId Indicates that the string representation of the ObjectId is used if the _id field is of type ObjectId; otherwise, the MD5 algorithm is used to compute the hash of the contents of the _id field. The string representation of an ObjectId is the hexadecimal representation of the 12 bytes that comprise an ObjectId. The MD5 algorithm provides better performance than the secure hashing algorithms (SHA). ObjectId is the default value and it is suitable for most situations.Important: Use the default unless a unique constraint violation is reported even though all documents have a unique _id field. In that case, you might need to use a non-default algorithm, such as SHA-256 or SHA-512. SHA-1 Indicates that the SHA-1 hashing algorithm is used to derive an identifier from the _id field. SHA-256 Indicates that the SHA-256 hashing algorithm is used to derive an identifier from the _id field. SHA-512 Indicates that the SHA-512 hashing algorithm is used to derive an identifier from the _id field. This option generates the most unique values, but uses the most processor resources. include This optional parameter specifies the properties file to reference. The path can be absolute or relative. For more information, see Running multiple wire listeners. >>-include=--properties_file >< listener.onException This optional parameter specifies an ordered list of actions to take if an exception occurs that is not handled by the processing layer. .-reply >>-listener.onException=--+-closeSession >< '-shutdownListener-' reply When an unhandled exception occurs, reply with the exception message. This is the default value. closeSession When an unhandled exception occurs, close the session. shutdownListener When an unhandled exception occurs, shut down the wire listener. listener.hostName This optional parameter specifies the host name of the wire listener. The host name determines the network adapter or interface that the wire listener binds the server socket to. Tip: If you enable the wire listener to be accessed by clients on remote hosts, turn on authentication by using the authentication.enable parameter. .-localhost-. >>-listener.hostName=--+-hostname >< '-* ' localhost Bind the wire listener to the localhost address. The wire listener is not accessible from clients on remote machines. This is the default value. hostname The host name or IP address of host machine where the wire listener binds to. * The wire listener can bind to all interfaces or addresses. listener.port This optional parameter specifies the port number to listen on for incoming connections from MongoDB clients. This value can be overridden from the command line by using the -port argument. The default value is Important: If you specify a port number that is less than 1024, the user that starts the wire listener might require additional operating system privileges. >>-listener.port=--+-port_number >< listener.type This optional parameter specifies the type of wire listener to start. .-mongo-. >>-listener.type=--+-rest >< mongo Connect the wire listener to the MongoDB API. This is the default value. rest Connect the wire listener to the REST API. response.documents.count.default This optional parameter specifies the default number of documents in a single response to a query. The default value is 100. >>-response.documents.count.default=--+-default_docs >< response.documents.count.maximum This optional parameter specifies the maximum number of documents in a single response to a query. The default value is >>-response.documents.count.maximum=--+-max_docs >< response.documents.size.maximum This optional parameter specifies the maximum size, in bytes, of all documents in a single response to a query. The default value is >>-response.documents.size.maximum=--+-max_size >< sharding.enable This optional parameter indicates whether to enable the use of commands and queries on sharded data. .-false-. >>-sharding.enable=--+-true >< false Do not enable the use of commands and queries on sharded data. This is the default value. true Enable the use of commands and queries on sharded data. sharding.parallel.query.enable This optional parameter indicates whether to enable the use of parallel sharded queries. Parallel sharded queries require that the SHARD_ID configuration parameter be set to unique IDs on all shard servers. The sharding.enable parameter must also be set to true. .-false-. >>-sharding.parallel.query.enable=--+-true >< false Do not enable parallel sharded queries. This is the default value. true Enable parallel sharded queries. These parameters provide configuration options for JSON commands and operations.collection.informix.options This optional parameter specifies which table options for shadow columns or auditing to use when creating a JSON collection. .-, V | >>-collection.informix.options=[ ]----->< +-"audit" +-"crcols"----+ +-"erkey" +-"replcheck"-+ '-"vercols"---' audit Use the AUDIT option of the CREATE TABLE statement to create a table to be included in the set of tables that are audited at the row level if selective row-level is enabled. crcols Use the CRCOLS option of the CREATE TABLE statement to create two shadow columns that Enterprise Replication uses for conflict resolution. erkey Use the ERKEY option of the CREATE TABLE statement to create the ERKEY shadow columns that Enterprise Replication uses for a replication key. replcheck Use the REPLCHECK option of the CREATE TABLE statement to create the ifx_replcheck shadow column that Enterprise Replication uses for consistency checking. vercols Use the VERCOLS option of the CREATE TABLE statement to create two shadow columns that Informix uses to support update operations on secondary servers. command.listDatabases.sizeStrategy This optional parameter specifies a strategy for calculating the size of your database when the MongoDB listDatabases command is run. The listDatabases command estimates the size of all collections and collection indexes for each database. However, relational tables and indexes are excluded from this size calculation. Important: The MongoDB listDatabases command performs expensive and CPU-intensive computations on the size of each database in the database server instance. You can decrease the expense by using the command.listDatabases.sizeStrategy parameter. .-estimate >>-command.listDatabases.sizeStrategy=---+-{estimate:n} >< +-compute +-none '-perDatabaseSpace-' estimate Estimate the size of the database by sampling documents in every collection. This is the default value. This strategy is the equivalent of {estimate: 1000}, which takes a sample size of 0.1% of the documents in every collection. This is the default value.command.listDatabases.sizeStrategy=estimate estimate: n Estimate the size of the database by sampling one document for every n documents in every collection. The following example estimates the collection size by using sample size of 0.5% or 1/200th of the documents:command.listDatabases.sizeStrategy={estimate:200} compute Compute the exact size of the database.command.listDatabases.sizeStrategy=compute none List the databases but do not compute the size. The database size is listed as 0.command.listDatabases.sizeStrategy=none perDatabaseSpace Calculate the size of a database by adding the sizes for all dbspaces, sbspaces, and blobspaces that are assigned to the tenant database. Important: The perDatabaseSpace option applies only to tenant databases that are created by the multi-tenancy feature. update.client.strategy This optional parameter specifies the method that is used by the wire listener to send updates to the database server. When the wire listener does the update processing, it queries the server for the existing document and then updates the document. .-updatableCursor-. >>-update.client.strategy=---+-deleteInsert >< updatableCursor Updates are sent to the database server by using an updatable cursor. This is the default value. deleteInsert The original document is deleted when the updated document is inserted.Important: If the collection is sharded, you must use this method. update.mode This optional parameter determines where document updates are processed. The default value is update.mode=client. .-client-. >>-update.mode=---+-mixed >< client Use the wire listener to process updates. For example, if your document updates are complicated or use document replacement, you can use client to process these updates by using the wire listener. This is the default value. mixed Attempt to process updates on the database server first, then fallback to the wire listener. For example, if your document updates consist mainly of single operation updates on a single field (for example, $set, $inc), you can use mixed to process these updates directly on the server. These parameters provide database resource management options.database.buffer.enable Prerequisite: database.log.enable=true This optional parameter indicates whether to enable buffered logging when you create a database by using the wire listener. .-true--. >>-database.buffer.enable=--+-false >< true Enable buffered logging. This is the default value. false Do not enable buffered logging. database.create.enable This optional parameter indicates whether to enable the automatic creation of a database, if a database does not exist. .-true--. >>-database.create.enable=--+-false >< true If a database does not exist, create a database. This is the default value. false If a database does not exist, do not create a database. With this option, you can access only existing databases. database.dbspace Prerequisite: dbspace.strategy=fixed This optional parameter specifies the name of the dbspace databases that are created. The default value is database.dbspace=rootdbs. .-rootdbs >>-database.dbspace=--+-dbspace_name >< database.locale.default This optional parameter specifies the default locale to use when a database is created by using the wire listener. The default value is en_US.utf8. .-en_US.utf8-. >>-database.locale.default=--+-locale >< database.log.enable This optional parameter indicates whether to create databases that are enabled for logging. .-true--. >>-database.log.enable=--+-false >< true Create databases that are enabled for logging. This is the default value. Use the database.buffer.enable parameter to enable buffered logging. false Do not create databases that are enabled for logging. database.share.close.enable Prerequisite: database.share.enable=true This optional parameter indicates whether to close a shared database and its associated resources, including connection pools, when the number of active sessions drops to zero. .-true--. >>-database.share.close.enable=--+-false >< true Close a shared database when the number of active sessions drops to zero. This is the default value. false Keep the shared database open when the number of active sessions drops to zero.Important: If shared databases are enabled and this property is set to false, the connection pool associated with a database is never closed. database.share.enable This optional parameter indicates whether to share database objects and associated resources. For example, you can share connection pools between sessions. .-true--. >>-database.share.enable=--+-false >< true Share database objects and associated resources. Use the database.share.enable parameter to control when to close the shared database. This is the default value. false Do not share database objects and associated resources. dbspace.strategy This optional parameter specifies the strategy to use when determining the location of new databases, tables, and indexes. .-autolocate-. >>-dbspace.strategy=--+-fixed >< autolocate The database server automatically determines the dbspace for the new databases, tables, and indexes. This is the default value. fixed Use a specific dbspace, as specified by the database.dbspace property. fragment.count This optional parameter specifies the number of fragments to use when creating a collection. If you specify 0, the database server determines the number of fragments to create. If you specify a fragment_num greater than 0, that number of fragments are created when the collection is created. The default value is 0. >>-fragment.count=--+-fragment_num >< jdbc.afterNewConnectionCreation This optional parameter specifies one or more SQL commands to run after a new connection to the database is created. .-, V | >>-jdbc.afterNewConnectionCreation=[---"sql_command"-+-] >< For example, to accelerate queries run through the wire listener by using Informix Warehouse Accelerator: jdbc.afterNewConnectionCreation=["SET ENVIRONMENT USE_DWA 'ACCELERATE ON'"] These parameters provide options for MongoDB compatibility.compatible.maxBsonObjectSize.enable This optional parameter indicates whether the maximum BSON object size is compatible with MongoDB.Tip: If you insert a BSON document by using an SQL operation, Informix supports a maximum document size of 2 GB. .-false-. >>-compatible.maxBsonObjectSize.enable=--+-true >< false Use a maximum document size of 256 MB with the wire listener. This is the default value. true Use a maximum document size of 16 MB. The maximum document size for MongoDB is 16 MB. mongo.api.version This optional parameter specifies the MongoDB API version with which the wire listener is compatible. The version affects authentication methods as well as MongoDB commands. >>-mongo.api.version= >< '-3.0-' Important: Do not set mongo.api.version=3.0 if you want to use the REST API or database server authentication. See User authentication with the wire listener. update.one.enable This optional parameter indicates whether to enable support for updating a single JSON document. Important: The update.one.enable parameter applies to JSON collections only. For relational tables, the MongoDB multi-parameter is ignored and all documents that meet the query criteria are updated. .-false-. >>-update.one.enable=--+-true >< false All collection updates are treated as multiple JSON document updates. This is the default value. With the update.one.enable=false setting, the MongoDB db.collection.update multi-parameter is ignored and all documents that meet the query criteria are updated. true Allow updates on collections to a single document or multiple documents. With the update.one.enable=true setting, the MongoDB db.collection.update multi-parameter is accepted. The db.collection.update multi-parameter controls whether you can update a single document or multiple documents. These parameters provide performance options for databases and collections.delete.preparedStatement.cache.enable This optional parameter indicates whether to cache prepared statements that delete documents for reuse. .-true--. >>-delete.preparedStatement.cache.enable=--+-false >< true Use a prepared statement cache for statements that delete documents. This is the default value. false Do not use a prepared statement cache for statements that delete documents. A new statement is prepared for each query. insert.batch.enable If multiple documents are sent as a part of a single INSERT statement, this optional parameter indicates whether to batch document inserts operations into collections. .-true--. >>-insert.batch.enable=--+-false >< true Batch document inserts into collections by using JDBC batch calls to perform the insert operations. This is the default value. false Do not batch document insert operations into collections. insert.batch.queue.enable This optional parameter indicates whether to queue INSERT statements into larger batches. You can improve insert performance by queuing INSERT statements, however, there is decreased durability. This parameter batches all INSERT statements, even a single INSERT statement. These batched INSERT statements are flushed at the interval that is specified by the insert.batch.queue.flush.interval parameter, unless another operation arrives on the same collection. If another operation arrives on the same collection, the batch inserts are immediately flushed to the database server before proceeding with the next operation. .-false-. >>-insert.batch.queue.enable=--+-true >< false Do not queue INSERT statements. This is the default. true Queue INSERT statements into larger batches. Use the insert.batch.queue.flush.interval parameter to specify the amount of time between insert queue flushes. insert.batch.queue.flush.interval Prerequisite: insert.batch.queue.enable=true This optional parameter specifies the number of milliseconds between flushes of the insert queue to the database server. The default value is insert.batch.queue.flush.interval=100. >>-insert.batch.queue.flush.interval= > >--+-flush_interval_time >< index.cache.enable This optional parameter indicates whether to enable index caching on collections. To write the most efficient queries, the wire listener must be aware of the existing BSON indexes on your collections. .-true--. >>-index.cache.enable=--+-false >< true Cache indexes on collections. This is the default value. false Do not cache indexes on collections. The wire listener queries the database for indexes each time a collection query is translated to SQL. index.cache.update.interval This optional parameter specifies the amount of time, in seconds, between updates to the index cache on a collection table. The default value is index.cache.update.interval=120. >>-index.cache.update.interval=--+-cache_update_interval >< insert.preparedStatement.cache.enable This optional parameter indicates whether to cache the prepared statements that are used to insert documents. .-true--. >>-insert.preparedStatement.cache.enable=--+-false >< true Cache the prepared statements that are used to insert documents. This is the default value. false Do not cache the prepared statements that are used to insert documents. preparedStatement.cache.enable This optional parameter indicates whether to cache prepared statements for reuse. .-true--. >>-preparedStatement.cache.enable=--+-false >< true Use a prepared statement cache. This is the default value. false Do not use a prepared statement cache. A new statement is prepared for each query. preparedStatement.cache.size This optional parameter specifies the size of the least-recently used (LRU) map that is used to cache prepared statements. The default value is preparedStatement.cache.size=20. >>-preparedStatement.cache.enable=--+-LRU_size >< The parameters provide security enablement options.authentication.enable This optional parameter indicates whether to enable user authentication. You can choose to authenticate MongoDB clients in the wire listener with a MongoDB authentication method, or in the database server, with a pluggable authentication module. .-false-. >>-authentication.enable=--+-true >< false Do not authenticate users. This is the default value. true Authenticate users. Use the authentication.localhost.bypass.enable parameter to control the type of authentication. authentication.localhost.bypass.enable Prerequisite: authentication.enable=true If you connect from the localhost to the Informix admin database, and the admin database contains no users, this optional parameter indicates whether to grant full administrative access. The Informix admin database is similar to the MongoDB admin database. The Informix authentication.localhost.bypass.enable parameter is similar to the MongoDB enableLocalhostAuthBypass parameter. .-true--. >>-authentication.localhost.bypass.enable=--+-false >< true Grant full administrative access to the user. This is the default value. false Do not grant full administrative access to the user. command.blacklist This optional parameter lists commands that are removed from the command registry and cannot be called. By default, the black list is empty. .-, V | >>-command.blacklist=[---command-+-] >< db.authentication This optional parameter specifies the user authentication method. See User authentication with the wire listener. .-mongodb-cr >>-db.authentication=--+-informix-mongodb-cr >< mongdb-cr Authenticate through the wire listener with a MongoDB authentication method. The MongoDB authentication method depends on the setting of the mongo.api.version parameter. informix-mongodb-cr Authenticate through the database server with a pluggable authentication module. listener.admin.ipAddress This optional parameter specifies the IP address for the administrative host. Must be a loopback IP address. The default value is Important: If you specify an address that is not a loopback IP address, an attacker might perform a remote privilege escalation and obtain administrative privileges without knowing a user password. >>-listener.admin.ipAddress=ip_address >< listener.authentication.timeout This optional parameter specifies the number of milliseconds that the wire listener waits for a client connection to authenticate. The default value is 0, which indicates that the wire listener waits indefinitely for client connections to authenticate. >>-listener.authentication.timeout=milliseconds >< listener.http.accessControlAllowCredentials This optional parameter indicates whether to display the response to the request when the omit credentials flag is not set. When this parameter is part of the response to a preflight request, it indicates that the actual request can include user credentials. .-true--. >>-listener.http.accessControlAllowCredentials=--+-false >< true Display the response to the request. This is the default value. false Do not display the response to the request. listener.http.accessControlAllowHeaders This optional parameter, which is part of the response to a preflight request, specifies the header field names that are used during the actual request. You must specify the value by using a JSON array of strings. Each string in the array is the case-insensitive header field name. The default value is listener.http.accessControlAllowHeaders=["accept","cursorId","content-type"]. >>-listener.http.accessControlAllowHeaders= > .-"accept","cursorId","content-type"-. | .-, | | V | | >--[-+---"--header_field_name--" ] >< For example, to allow the headers foo and bar in a request:listener.http.accessControlAllowHeaders=["foo","bar"] listener.http.accessControlAllowMethods This optional parameter, which is part of the response to a preflight request, specifies the REST methods that are used during the actual request. You must specify the value by using a JSON array of strings. Each string in the array is the name of an HTTP method that is allowed. The default value is listener.http.accessControlAllowMethods=["GET","PUT","POST","DELETE","OPTIONS"]. >>-listener.http.accessControlAllowMethods= > .-"GET","PUT","POST","DELETE","OPTIONS"-. | .-, | | V | | >--[-+---"--rest_method--" ] >< listener.http.accessControlAllowOrigin This optional parameter specifies which uniform resource identifiers (URI) are authorized to receive responses from the REST listener when processing cross-origin resource sharing (CORS) requests. You must specify the value by using a JSON array of strings, with a separate string in the array for each value for the HTTP Origin header in a request. The values that are specified in this parameter are validated to ensure that they are identical to the Origin header. HTTP requests include an Origin header that specifies the URI that served the resource that processes the request. When a resource from a different origin is accessed, the resource is validated to determine whether sharing is allowed. The default value, listener.http.accessControlAllowOrigin={"$regex":".*"}, means that any origin is allowed to perform a CORS request. >>-listener.http.accessControlAllowOrigin= > .-"$regex":".*"--. >--{-+-authorized_URI-+-} >< Here are some usage examples:Grant access to the localhost: listener.http.accessControlAllowOrigin=" Grant access to all hosts in the subnet /24. The first 3 segments are validated as 10, 168, and 8, and the fourth segment is validated as a value :listener.http.accessControlAllowOrigin={"$regex":"^ d\\\\d?|2[0-4]\\\\d|25[0-5])$" } Grant access to all hosts in the subnet /24. The first 3 segments are validated as 10, 168, and 8, and the fourth segment must contain one or more digits: listener.http.accessControlAllowOrigin={"$regex": "^ } listener.http.accessControlExposeHeaders This optional parameter specifies which headers of a CORS request to expose to the API. You must specify the value by using a JSON array of strings. Each string in the array is the case-insensitive name of a header to be exposed. The default value is listener.http.accessControlExposeHeaders=["cursorId"]. >>-listener.http.accessControlExposeHeaders= > .-["cursorId"]-. >--+-CORS_headers >< For example, to expose the headers foo and bar to a client: listener.http.accessControlExposeHeaders=["foo","bar"] listener.http.accessControlMaxAge This optional parameter specifies the amount of time, in seconds, that the result of a preflight request is cached in a preflight result cache. A value of 0 indicates that the Access-Control-Max-Age header is not included in the response to a preflight request. A value greater than 0 indicates that the Access-Control-Max-Age header is included in the response to a preflight request. The default value is listener.http.accessControlMaxAge=0. >>-listener.http.accessControlMaxAge= > >--+-preflight_result_cache_time >< listener.http.headers This optional parameter specifies the information to include in the HTTP headers of responses, as a JSON document. The default value is no additional information in the HTTP headers. >>-listener.http.headers=JSON_document >< For example, you set this parameter to the following value: listener.http.headers={ "Access-Control-Allow-Origin" : " "Access-Control-Allow-Credentials" : "true" } Then the HTTP headers for all responses look like this:Access-Control-Allow-Origin : Access-Control-Allow-Credentials : true listener.rest.cookie.domain This optional parameter specifies the name of the cookie that is created by the REST wire listener. If not specified, the domain is the default value as determined by the Apache Tomcat web server. >>-listener.rest.cookie.domain= >< '-rest_cookie_name-' listener.rest.cookie.httpOnly This optional parameter indicates whether to set the HTTP-only flag. .-true--. >>-listener.rest.cookie.httpOnly=--+-false >< true Set the HTTP-only flag. This flag helps to prevent cross-site scripting attacks. This is the default value. false Do not set the HTTP-only flag. listener.rest.cookie.length This optional parameter specifies the length, in bytes, of the cookie value that is created by the REST wire listener, before Base64 encoding. The default value is listener.rest.cookie.length=64. >>-listener.rest.cookie.length=--+-rest_cookie_length >< listener.rest.cookie.name This optional parameter specifies the name of the cookie that is created by the REST wire listener to identify a session. The default value is listener.rest.cookie.name=informixRestListener.sessionId. >>-listener.rest.cookie.name= > .-informixRestListener.sessionId-. >--+-rest_cookie_name >< listener.rest.cookie.path This optional parameter specifies the path of the cookie that is created by the REST wire listener. The default value is listener.rest.cookie.path=/. .-/ >>-listener.rest.cookie.path=--+-rest_cookie_path >< listener.rest.cookie.secure This optional parameter indicates whether the cookies that are created by the REST wire listener have the secure flag on. The secure flag prevents the cookies from being used over an unsecure connection. .-false-. >>-listener.rest.cookie.secure=--+-true >< false Turn off the secure flag. This is the default value. true Turn on the secure flag. listener.ssl.algorithm This optional parameter specifies the Service Provider Interface (SPI) for the KeyManagerFactory that is used to access the network encryption keystore. On an Oracle Java Virtual Machine (JVM), this value is typically SunX509. On an IBM JVM, this value is typically IbmX509. The default value is no SPI.Important: Do not set this property if you are not familiar with Java Cryptography Extension (JCE). >>-listener.ssl.algorithm=SPI >< listener.ssl.ciphers This optional parameter specifies a list of Secure Sockets Layer (SSL) or Transport Layer Security (TLS) ciphers to use with network encryption. The default value is no ciphers, which means that the default list of enabled ciphers for the JVM are used.Important: Do not set this property if you are not familiar with Java Cryptography Extension (JCE) and the implications of using multiple ciphers. Consult a security expert for advice. .-, V | >>-listener.ssl.ciphers=---cipher >< You can include spaces between ciphers. For example, you can set the following ciphers:listener.ssl.ciphers=TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV listener.ssl.enable This optional parameter enables SSL or TLS network encryption on the socket for client connections. .-false-. >>-listener.ssl.enable=--+-true >< false Disable network encryption. This is the default. true Allow network encryption. listener.ssl.key.alias This optional parameter specifies the alias, or identifier, of the entry into the keystore. The default value is no alias, which indicates that the keystore contains one entry. If the keystore contain more than one entry and a key password is needed to unlock the keystore, set this parameter to the alias of the entry that unlocks the keystore. >>-listener.ssl.key.alias=alias >< This parameter is effective when the listener.ssl.enable parameter is set to true. listener.ssl.key.password This optional parameter specifies the password to unlock the entry into the keystore, which is identified by the listener.ssl.key.alias parameter. The default value is no password, which means to use the keystore password. If the entry into the keystore requires a password that is different from the keystore password, set this parameter to the entry password. >>-listener.ssl.key.password=password >< This parameter is effective when the listener.ssl.enable parameter is set to true. listener.ssl.keyStore.file This optional parameter specifies the fully-qualified path and file name of the Java keystore file to use for network encryption. The default value is no file. >>-listener.ssl.keyStore.file=file_path >< This parameter is effective when the listener.ssl.enable parameter is set to true. listener.ssl.keyStore.password This optional parameter specifies the password to unlock the Java keystore file for network encryption. The default value is no password. >>-listener.ssl.keyStore.password=password >< This parameter is effective when the listener.ssl.enable parameter is set to true. listener.ssl.keyStore.type This optional property specifies the provider identifier for the network encryption keystore SPI. The default value is JKS.Important: Do not set this property if you are not familiar with Java Cryptography Extension (JCE). >>-listener.ssl.keyStore.type=SPI >< This parameter is effective when the listener.ssl.enable parameter is set to true. listener.ssl.protocol This optional parameter specifies the SSL or TLS protocols. The default value is TLS. .-, V | >>-listener.ssl.protocol=---protocol >< This parameter is effective when the listener.ssl.enable parameter is set to true. security.sql.passthrough This optional parameter indicates whether to enable support for issuing SQL statements by using JSON documents. .-false-. >>-security.sql.passthrough=--+-true >< false Disable the ability to issue SQL statements by using the MongoDB API. This is the default. true Allow SQL statements to be issued by using the MongoDB API. These parameters provide wire listener resource management options. listener.idle.timeout This optional parameter specifies the amount of time, in milliseconds, that a client connection to the wire listener can idle before it is forcibly closed. You can use this parameter to close connections and free associated resources when clients are idle. The default value is 0 milliseconds.Important: When set to a nonzero value, the wire listener socket that is used to communicate with a MongoDB client is forcibly closed after the specified time. To the client, the forcible closure appears as an unexpected disconnection from the server the next time there is an attempt to write to the socket. >>-listener.idle.timeout=--+-idle_time >< listener.input.buffer.size This optional parameter specifies the size, in MB, of the input buffer for each wire listener socket. The default value is 8192 MB. >>-listener.input.buffer.size=--+-input_buffer_size >< listener.memoryMonitor.enable This optional parameter enables the wire listener memory monitor. When memory usage for the wire listener is high, the memory monitor attempts to reduce resources, such as removing cached JDBC prepared statements, removing idle JDBC connections from the connection pools, and reducing the maximum size of responses. .-true--. >>-listener.memoryMonitor.enable=--+-false >< true Enable the memory monitor. This is the default. false Disable the memory monitor. listener.memoryMonitor.allPoint This optional parameter specifies the maximum percentage of heap usage before the memory monitor reduces resources. The default value is 80. >>-listener.memoryMonitor.allPoint=percentage >< This parameter is effective when the listener.memoryMonitor.enable parameter is set to true. listener.memoryMonitor.diagnosticPoint This optional parameter specifies the percentage of heap usage before diagnostic information about memory usage is logged. The default value is 99. >>-listener.memoryMonitor.diagnosticPoint=percentage >< This parameter is effective when the listener.memoryMonitor.enable parameter is set to true. listener.memoryMonitor.zeroPoint This optional parameter specifies the percentage of heap usage before the memory manager reduces resource usage to the lowest possible levels. The default value is 95. >>-listener.memoryMonitor.zeroPoint=percentage >< This parameter is effective when the listener.memoryMonitor.enable parameter is set to true. listener.output.buffer.size This optional parameter specifies the size, in MB, of the output buffer for each listener socket. The default value is 8192 MB. >>-listener.output.buffer.size=--+-output_buffer_size >< listener.pool.admin.enable This optional parameter enables a separate thread pool for connections from the administrative IP address, which is set by the listener.admin.ipAddress parameter. The default value is false. A separate thread pool ensures that administrative connections succeed even if the listener thread pool lacks available resources. .-false-. >>-listener.pool.admin.enable=-+-true >< false Prevents a separate thread pool. This is the default. false Creates a separate thread pool for administrative connections. listener.pool.keepAliveTime This optional parameter specifies the amount of time, in seconds, that threads above the core pool size are allowed to idle before they are removed from the wire listener JDBC connection pool. The default value is 60 seconds. >>-listener.pool.keepAliveTime=--+-thread_idle >< listener.pool.queue.size This optional parameter specifies the number of requests to queue above the core wire listener pool size before expanding the pool size up to the maximum. A positive integer specifies the queue size to use before expanding the pool size up to the maximum. >>-listener.pool.queue.size= >< 0 Do not allocate a queue size for tasks. All new sessions are either run on an available or new thread up to the maximum pool size, or are rejected if the maximum pool size is reached. This is the default value. -1 Allocate an unlimited queue size for tasks. listener.pool.size.core This optional parameter specifies the maximum sustained size of the thread pool that listens for incoming connections from MongoDB clients. The default value is 128. >>-listener.pool.size.core=--+-max_thread_size >< listener.pool.size.maximum This optional parameter specifies the maximum peak size of the thread pool that listens for incoming connections from MongoDB clients. The default value is >>-listener.pool.size.maximum=--+-max_peak_thread_size >< listener.socket.accept.timeout This optional parameter specifies the number of milliseconds that a server socket waits for an accept() function. The default value is The value of 0 indicates to wait indefinitely. The value of this parameter can affect how quickly the wire listener shuts down. >>-listener.socket.accept.timeout=milliseconds >< listener.socket.read.timeout This optional parameter specifies the number of milliseconds to block when calling a read() function on the socket input stream. The default value is A value of 0 might prevent the wire listener from shutting down because the threads that poll the socket might never unblock. >>-listener.socket.read.timeout=milliseconds >< pool.connections.maximum This optional parameter specifies the maximum number of active connections to a database. The default value is 50. >>-pool.connections.maximum=--+-max_active_connect >< pool.idle.timeout This optional parameter specifies the minimum amount of time that an idle connection is in the idle pool before it is closed. The default value is 60 and the default time unit is seconds.Important: Set the unit of time in the pool.idle.timeunit parameter. The default value is seconds. >>-pool.idle.timeout=--+-min_idle_pool >< pool.idle.timeunit Prerequisite: pool.idle.timeout=time This optional parameter specifies the unit of time that is used to scale the pool.idle.timeout parameter. .-SECONDS >>-pool.idle.timeunit=--+-NANOSECONDS >< +-MICROSECONDS-+ +-MILLISECONDS-+ +-MINUTES +-HOURS '-DAYS ' SECONDS Use seconds as the unit of time. This is the default value. NANOSECONDS Use nanoseconds as the unit of time. MICROSECONDS Use microseconds as the unit of time. MILLISECONDS Use milliseconds as the unit of time. MINUTES Use minutes as the unit of time. HOURS Use hours as the unit of time. DAYS Use days as the unit of time. pool.lenient.return.enable This optional parameter suppresses the following checks on a connection that is being returned that might throw exceptions:An attempt to return a pooled connection that is already returned. An attempt to return a pooled connection that is owned by another pool. An attempt to return a pooled connection that is an incorrect type. .-false-. >>-pool.lenient.return.enable=-+-true >< false Connection checks are enabled. This is the default. false Connection checks are disabled. pool.lenient.dispose.enable This optional parameter suppresses the checks on a connection that is being disposed of that might throw exceptions. .-false-. >>-pool.lenient.dispose.enable=-+-true >< false Connection checks are enabled. This is the default. false Connection checks are disabled. pool.semaphore.timeout This optional parameter specifies the amount of time to wait to acquire a permit for a database connection. The default value is 5 and the default time unit is seconds.Important: Set the unit of time in the pool.semaphore.timeunit parameter. >>-pool.semaphore.timeout=--+-wait_time >< pool.semaphore.timeunit Prerequisite: pool.semaphore.timeout=wait_time This optional parameter specifies the unit of time that is used to scale the pool.semaphore.timeout parameter. .-SECONDS >>-pool.semaphore.timeunit=--+-NANOSECONDS >< +-MICROSECONDS-+ +-MILLISECONDS-+ +-MINUTES +-HOURS '-DAYS ' SECONDS Use seconds as the unit of time. This is the default value. NANOSECONDS Use nanoseconds as the unit of time. MICROSECONDS Use microseconds as the unit of time. MILLISECONDS Use milliseconds as the unit of time. MINUTES Use minutes as the unit of time. HOURS Use hours as the unit of time. DAYS Use days as the unit of time. pool.service.interval This optional parameter specifies the amount of time to wait between scans of the idle connection pool. The idle connection pool is scanned for connections that can be closed because they have exceeded their maximum idle time. The default value is 30.Important: Set the unit of time in the pool.service.timeunit parameter. >>-pool.service.interval=--+-wait_time >< pool.service.threads This optional parameter specifies the number of threads to use for the maintenance of connection pools that share a common service thread pool. The default value is 1. >>-pool.service.threads=number >< pool.service.timeunit Prerequisite: pool.service.interval=wait_time This optional parameter specifies the unit of time that is used to scale the pool.service.interval parameter. .-SECONDS >>-pool.service.timeunit=--+-NANOSECONDS >< +-MICROSECONDS-+ +-MILLISECONDS-+ +-MINUTES +-HOURS '-DAYS ' SECONDS Use seconds as the unit of time. This is the default value. NANOSECONDS Use nanoseconds as the unit of time. MICROSECONDS Use microseconds as the unit of time. MILLISECONDS Use milliseconds as the unit of time. MINUTES Use minutes as the unit of time. HOURS Use hours as the unit of time. DAYS Use days as the unit of time. pool.size.initial This optional parameter specifies the initial size of the idle connection pool. The default value is 0. >>-pool.size.initial=--+-idle_pool_initial_size >< pool.size.minimum This optional parameter specifies the minimum size of the idle connection pool. The default value is 0. >>-pool.size.minimum=--+-idle_pool_min_size >< pool.size.maximum This optional parameter specifies the maximum size of the idle connection pool. The default value is 50. >>-pool.size.maximum=--+-idle_pool_max_size >< pool.type This optional parameter specifies the type of pool to use for JDBC connections. The available pool types are: .-basic-----. >>-pool.type=--+-none >< +-advanced--+ '-perThread-' basic Thread pool maintenance of idle threads is run each time that a connection is returned. This is the default value. none No thread pooling occurs. Use this type for debugging purposes. advanced Thread pool maintenance is run by a separate thread. perThread Each thread is allocated a connection for its exclusive use. pool.typeMap.strategy This optional parameter specifies the strategy to use for distribution and synchronization of the JDBC type map for each connection in the pool. .-copy--. >>-pool.typeMap.strategy=--+-clone >< '-share-' copy Copy the connection pool type map for each connection. This is the default value. clone Clone the connection pool type map for each connection. share Share a single type map between all connections. You must use this strategy with a thread-safe type map. response.documents.size.minimum This optional parameter specifies the number of bytes for the lower threshold for the maximum response size, which is set by the response.documents.size.maximum parameter. The memory manager can reduce the response size to this size when resources are low. The default value is bytes. >>-response.documents.size.minimum=bytes >< This parameter is effective when the listener.memoryMonitor.enable parameter is set to true. © 2016 IBM Corporation

Wire Listener Enhancements – New Parameters
Suppress pooled connection checking with pool.lenient.return.enable and pool.lenient.dispose.enable. Specify the number of maintenance threads for connection pools with pool.service.threads. © 2016 IBM Corporation

Other New Wire Listener Enhancements
Authenticate wire listener connections with Informix You can configure the database server to authenticate MongoDB client users, who connect through the wire listener, with a Pluggable Authentication Module (PAM). Because you administer user accounts through the database server, you can audit user activities and configure fine-grained access control. In contrast, if you use MongoDB authentication, MongoDB clients connect to the database server as the wire listener user that is specified by the url parameter. Starting the wire listener for the REST API You no longer need to provide the path to tomcat when you start the wire listener for the REST API. © 2016 IBM Corporation

Other Enhancements Faster index transfer to secondary servers
When the LOG_INDEX_BUILD configuration parameter is enabled, the transfer of newly-created detached indexes to HDR or remote stand-alone secondary servers use light scans when possible, which leads to faster transfer rates. Easier cloning of database servers When you clone a replication or high-availability server with the ifxclone utility, you can include the new --createchunkfile (-k) option to automatically create the cooked chunks and mirror chunks on the target server that exist on the source server. ifxclone -T -L -S Boston -I P 543 -t Raleigh -i p 765 -d RSS –k (-k) - ifxclone now has short and long form names for each of its options. If source chunk is raw, ifxclone will create a cooked chunk on the target server. © 2016 IBM Corporation

Application Development
Re-optimize JDBC queries When you run queries through the Informix JDBC Driver, reoptimize previously prepared query plans: Set the new withReoptimization argument of the IfmxPreparedStatement.executeQuery method to true. Keep JDBC socket connections open Keep long-running JDBC socket connections from timing out due to inactivity. Set the IFX_SOC_KEEPALIVE environment variable to true when you open a socket connection with the Informix JDBC Driver. Avoid caching SQL statements with unpredictable query plans Some SQL statements produce significantly different query plans depending on the values of the placeholders that are passed to the database server when the statements are run. Using a cached query plan for such a statement might result in poor performance. Avoid caching an SQL statement whose query plan is unpredictable by including the AVOID_STMT_CACHE optimizer directive. © 2016 IBM Corporation

Automatic Update Statistics Database Prioritization
Assign a priority to each of your databases in the Auto Update Statistics (AUS) maintenance system. By default all databases have a medium priority. Assign specific databases a high or a low priority to ensure that statistics for your most important databases are updated first. Statistics for low priority databases are updated after high and medium priority databases, if time and resources permit. If you have a system with a production and a test database, you can assign the production database a high and the test database a low priority. You can also disable AUS for a database. You can set AUS priorities in the IBM OpenAdmin Tool (OAT) for Informix or by adding rows to the ph_threshold table in the sysadmin database. © 2016 IBM Corporation

Informix V12 and Guardium V10
Enhanced auditing of Informix databases with IBM Guardium Increased capabilities when you audit the user actions for an Informix database server with Guardium, version 10.0. Guardium can now mask sensitive data and audit, and if necessary, close, any Informix connection, regardless of connection protocol. Previously, Guardium audited and closed only TCP connections. After you set up the Guardium server, you start the ifxguard utility to monitor connections to your Informix databases. You can customize the behavior of the ifxguard utility by editing the ifxguard configuration file and by setting the IFXGUARD configuration parameter in the onconfig file. © 2016 IBM Corporation

Informix Warehouse Accelerator Monitoring
When you run the ondwa tasks command to monitor Informix Warehouse Accelerator queries, the command now displays client session information for running queries and basic information about queued queries. The client session information includes the session ID and the server number to which the client is connected. © 2016 IBM Corporation

Timeseries Show time series reference count
See the time series reference count in the metadata section of the output of the TSInfo function. The time series reference count is the number rows in time series tables that reference the same time series data in a container. You can now specify NULL instead of a dbspace name when you create containers with the TSCreateContainer procedure. The container is created in the same dbspace as the time series table, or, if the table is in a tenant database, the dbspace for the tenant database catalogs. This represents a new default, previously a dbspace name was required. © 2016 IBM Corporation

New Platforms – Informix 12
IBM POWER8® for ppc64le with Red Hat Enterprise Linux 7.1, SUSE Linux Enterprise Server 12 Ubuntu LTS. The spatial data feature is now available on the following platforms: IBM Power Series® 64-bit with Red Hat Enterprise Linux ES releases 5.3, 6, and 7 SUSE SLES 11 IBM zSeries 64-bit Red Hat Enterprise Linux ES releases 5.3 and 6, © 2016 IBM Corporation

Agenda COALESCE function Faster updates of JSON documents
Consistent hashing for shard servers TimeSeries Spatiotemporal searching Improvements TimeSeries loader with auto spatiotemporal indexing Improved TimeSeries search pattern matching Limit future data for TimeSeries rolling window containers Enhancements for TimeSeries hertz data Longer fragmentation schemes for TimeSeries virtual tables TimeSeries Aggregation Queries Convert spatial data to GeoJSON format MQTT Protocol Support MongoDB 3.2 API Support Informix Warehouse Accelerator & POWER 8 Linux in little Endian © 2016 IBM Corporation

COALESCE Function You can now evaluate a series of expressions to return the first non-null value by running the COALESCE function. The expressions are evaluated in the order specified, and the result of the function is the first value that is not null. The result of the COALESCE function returns NULL only if all the arguments are null. The expressions can return any data type that can be cast to a common compatible data type. Cannot be a host variable or a BYTE or TEXT object © 2016 IBM Corporation

BSON_UPDATE Enhancements
The BSON_UPDATE SQL function allows SQL users to update the contents of a BSON column within a JSON or BSON document with one or more MongoDB update operators. Prior to xC7, the BSON_UPDATE function allowed for the following Mongo_DB update operators to be used: $set $inc $unset Now, the following are additionally allowed from the database server: MongoDB array update operators MongoDB array update operator modifiers $addToSet $each $pop $position $pullAll $slice $push $sort © 2016 IBM Corporation

BSON_UPDATE Usage BSON_UPDATE is a function to update a BSON document with the supported MongoDB API update operators. Update operations are run sequentially: 1) The original document is updated 2) The updated document is then the input to the next update operator. 3) The BSON_UPDATE function returns the final BSON document. Which then needs to be converted to JSON if to be human read To include JavaScript expressions in update operations, evaluate the expressions on the client side and supply the final result of the expression in a field-value pair. © 2016 IBM Corporation

Some Notes The MongoDB array update operators $pull, $pushAll work within wire listener based operations and use a different strategy to perform document updates that do not involve the BSON_UPDATE command or the database server; JSON operations that do not use the database server. It would appear the MongoDB API update operator ‘$’ is not supported currently, as you receive the following error message: “9659: The server does not support the specified UPDATE operation on JSON documents.” © 2016 IBM Corporation

Wire Listener Processing Change
The wire listener now sends document updates to the database server first by default. Previously, the wire listener processed document updates by default. The default setting of the update.mode parameter in the wire listener configuration file is now mixed instead of client. The wire listener falls back to the client in mixed mode when the database server cannot process the updates. © 2016 IBM Corporation

Quickly Add or Remove Shard Servers With Consistent Hashing
Quickly add or remove a shard server by using the new consistent hashing distribution strategy to shard data. With consistent hash-based sharding, the data is automatically distributed between shard servers in a way that minimizes the data movement when you add or remove shard servers. The original hashing algorithm redistributes all the data when you add or remove a shard server. You can specify the consistent hashing strategy when you run the cdr define shardCollection command. © 2016 IBM Corporation

Consistent Hash-based Sharding
When a consistent hash-based sharding definition is created, Informix uses a hash value of a specific defined column or field to distribute data to servers of a shard cluster in a consistent pattern. If a shard server is added or removed, the consistent hashing algorithm redistributes a fraction of the data. Specify how many hashing partitions to create on each shard server: The default is 3. If more than the default number of hashing partitions are created, the more evenly the data is distributed among shard servers. If more than 10 hashing partitions are specified, the resulting SQL statement to create the sharded table might fail because it exceeds the SQL statement maximum character limit. © 2016 IBM Corporation

cdr define shardCollection (1)
Below is a sharding definition that is named collection_1. Rows that are inserted on any of the shard servers are distributed, based on a consistent hash algorithm, to the appropriate shard server. The b column in the customers table that is owned by user john is the shard key. Each shard server has three hashing partitions. cdr define shardCollection collection_1 db_1:john.customers --type=delete --key=b --strategy=chash --partitions=3 --versionCol=column_3 g_shard_server_1 g_shard_server_2 g_shard_server_3 ER verifies a replicated row or document was not updated before the row or document can be deleted on the source server. Each shard server has a partition range calculated on the server group name and data distributed according to the following sharding definition which is very data dependent: (over) © 2016 IBM Corporation

Consistent Hashing Index Example
To create three partitions on each shard server: cdr define shardCollection collection_1 db_1:informix.customers --type=delete --key=b --strategy=chash --partitions=3 --versionCol=column_3 g_shard_server_1 g_shard_server_2 g_shard_server_3 Change dynamically the number of hashing partitions per shard server by running the cdr change shardCollection command. cdr change shardCollection collection1 - –partitions=4 © 2016 IBM Corporation

cdr define shardCollection (2)
g_shard_server_1 (mod(abs(ifx_checksum(b::LVARCHAR, 0)), 10000) between 4019 and 5469) or (mod(abs(ifx_checksum(b::LVARCHAR, 0)), 10000) between 5719 and 6123) or (mod(abs(ifx_checksum(b::LVARCHAR, 0)), 10000) between 2113 and 2652) g_shard_server_2 (mod(abs(ifx_checksum(b::LVARCHAR, 0)), 10000) between 6124 and 7415) or (mod(abs(ifx_checksum(b::LVARCHAR, 0)), 10000) between 5470 and 5718) or (mod(abs(ifx_checksum(b::LVARCHAR, 0)), 10000) between 7416 and 7873) g_shard_server_3 (mod(abs(ifx_checksum(b::LVARCHAR, 0)), 10000) between 2653 and 3950) or mod(abs(ifx_checksum(b::LVARCHAR, 0)), 10000) >= 7874 or mod(abs(ifx_checksum(b::LVARCHAR, 0)), 10000) < 2113 or (mod(abs(ifx_checksum(b::LVARCHAR, 0)), 10000) between 3951 and 40 © 2016 IBM Corporation

Trigger Spatiotemporal Indexing During TS Data Loads
If a spatiotemporal subtrack table exists for a time series, trigger indexing on spatiotemporal data when you load time series data by Set the writeflag parameter to 512 or 1024 in the functions: TSL_Commit TSL_FlushAll TSL_Flush © 2016 IBM Corporation

TSL_Commit Function Flushes data for all containers to disk in multiple transactions. Syntax: TSL_Commit( handle lvarchar, writeflag integer DEFAULT 1, commit_interval integer DEFAULT NULL) returns integer handle Table and column name returned by the TSL_Attach or the TSL_Init function. writeflag (Optional) An integer that is the sum of flag values representing if: 1 - Duplicate elements are allowed for irregular time series Cannot be combine with 5 5 - Duplicate elements replace existing elements Cannot combine with 1 256 - Logging is reduced 512 - Spatiotemporal indexing is triggered Cannot combine with 1024 1024 – Spatiotemporal index rebuilt for time series instances receiving new data Cannot combine with 512. commit_interval (Optional) Positive integer representing the maximum number of elements to insert per transaction. Default is 10000, if the argument is omitted or set to NULL © 2016 IBM Corporation

TSL_Commit Purpose and Usage
Writes time series data to disk as part of a loader program Run TSL_Commit within a loader session initialized by the TSL_Init function Use TSL_Commit to save data loaded by the TSL_Put, TSL_PutSQL, or TSL_PutRow functions Use when the data loaded is too large for your logical log to flush as one transaction. TSL_Commit commits transactions after flushing the specified number of elements, or when all elements for a container are flushed. A commit_interval of 5000 and 10,000 elements load into a container TSL_Commit commits 2 transactions Load 10,000 elements in equal amounts into 5 containers TSL_Commit commits 5 transactions of 2000 elements If TSL_Commit runs within an explicit transaction TSL_Commit does not commit transactions If duplicate elements are allowed for irregular time series with the writeflag argument value of 1, TSL_Commit inserts data in the same way as the PutElem function Duplicate elements can replace existing elements that have the same timestamps with the writeflag argument value of 5 © 2016 IBM Corporation

TSL_Commit Purpose and Usage
If reduced logging is on with the writeflag argument, TSL_Commit must run in a transaction that can include only other functions that use reduced logging with the TSOPEN_REDUCED_LOG flag. Elements saved are not visible by dirty reads until after a transaction commits. If you build the spatiotemporal index with the writeflag argument, you must have an existing subtrack table for the time series Build the spatiotemporal index incrementally to append new data after the latest time stamp, or Delete the existing spatiotemporal subtrack table and indexes and rebuild them. © 2016 IBM Corporation

TSL_FlushAll Function
Flushes data for all containers to disk in a single transaction. Syntax: TSL_FlushAll( handle lvarchar, writeflag integer DEFAULT 1,) returns integer handle Table and column name returned by the TSL_Attach or the TSL_Init function. writeflag (Optional) An integer that is the sum of flag values representing if: 1 - Duplicate elements are allowed for irregular time series Cannot be combine with 5 5 - Duplicate elements replace existing elements Cannot combine with 1 256 - Logging is reduced 512 - Spatiotemporal indexing is triggered Cannot combine with 1024 1024 – Spatiotemporal index rebuilt for time series instances receiving new data Cannot combine with 512. Returns an integer representing function execution status A positive integer = The number of elements that were inserted -1 = Process was interrupted or encountered a severe error © 2016 IBM Corporation

-1 = Process was interrupted or encountered a severe error
TSL_Flush Function Flushes data for one or all containers to disk in a single transaction. Syntax: TSL_Flush( handle lvarchar, writeflag integer DEFAULT 1,) returns integer handle Table and column name returned by the TSL_Attach or the TSL_Init function. container (Optional) The container identifier. Default is NULL, which indicates all containers writeflag (Optional) An integer that is the sum of flag values representing if: 1 - Duplicate elements are allowed for irregular time series Cannot be combine with 5 5 - Duplicate elements replace existing elements Cannot combine with 1 256 - Logging is reduced 512 - Spatiotemporal indexing is triggered Cannot combine with 1024 1024 – Spatiotemporal index rebuilt for time series instances receiving new data Cannot combine with 512. Returns an integer representing function execution status A positive integer = The number of elements that were inserted -1 = Process was interrupted or encountered a severe error © 2016 IBM Corporation

TSL_Commit, TSL_FlushAll, TSL_Flush
Some notes You must supply a value for the duplicate element behavior (either 1 or 5) The following is a list of possible values for this argument: 1 5 257 ( ) 261 ( ) 513 ( ) 517 ( ) 769 ( ) 773 ( ) 1025 ( ) 1029 ( ) 1281 ( ) 1285 ( ) execute function TSL_Commit(‘ts_data|many_reads’,513,10000); execute function TSL_FlushALL(‘ts_data|many_reads’,513); © 2016 IBM Corporation

Improved TimeSeries Pattern Match Searching
Create a pattern match index or run a pattern match search on a field in a BSON document. The BSON document must be in a BSON column the TimeSeries subtype and the field must hold numeric data. Execute the TSCreatePatternIndex function or the TSPatternMatch function and specify the BSON column and field name. With the TSCreatePatternIndex function with new beginning or ending times you extend the time range of an existing pattern match index to incrementally update the index. You can extend the index time range in either direction, or both directions, but the existing and new time ranges must overlap. © 2016 IBM Corporation

Future Partition Number Limits in Rolling Window
Limit the number of partitions for future dates in rolling window containers. Limiting partitions for future data protects the partition for current data from being destroyed. When creating rolling window containers with the TSContainerCreate function, specify the maximum number of future partitions. Limit future partitions for existing rolling window containers with the TSContainerManage function. © 2016 IBM Corporation

Improved Spatiotemporal Searching
Track at-rest objects and objects temporarily suffering signal-loss. Speed indexing of new data via parallelized multiple Scheduler tasks. Alternatively, you can configure time series loader functions to trigger spatiotemporal indexing as time series data is saved to disk. Set storage space, extent sizes for spatiotemporal data and indexes. No limits on time series table configuration or the number of rows: You can index spatiotemporal data in any standard or tenant database Location data can be in a BSON column within the TimeSeries subtype Time series data can be compressed or have a hertz frequency Distance measurements now use a spherical calculation that is based on longitude and latitude coordinates Previously used a Euclidean calculation that is based on the Cartesian system. Spatiotemporal data and indexes from a previous release of Informix must be dropped and re-created All spatiotemporal functions are renamed, however, applications that use the previous function names still run. © 2016 IBM Corporation

Prerequisites Before indexing spatiotemporal data, decide how to configure the data and where to store the spatiotemporal tables and indexes. When starting the spatiotemporal indexing process, a subtrack table is created for the time series column in the time series base table: Subtrack table contains trajectories that track where objects move, but also store information about when objects are stationary or do not have a signal. Subtrack table is indexed and the spatiotemporal search system tables are populated with information about the subtrack table and the time series. Set the definitions for spatiotemporal data, storage spaces, and extent sizes in the BSON parameters document when you run the STS_SubtrackCreate function. You can set default parameters for the database by running the STS_SetDefaultParameters function. © 2016 IBM Corporation

Prerequisites You can configure the data in the subtrack table by setting the following definitions Trajectories for moving objects: Regulate the size of a trajectory by setting how often to generate readings for a trajectory, the maximum duration of a trajectory, and the maximum area of the bounding box around the trajectory Stationary objects: Set the minimum length of time and the maximum distance that an object can move and still be considered stationary No data conditions: Set the minimum length of time for a no data condition © 2016 IBM Corporation

Prerequisites Storage space
Adequate storage space before you start indexing spatiotemporal data Specify storage spaces and extent sizes for each subtrack objects: The subtrack table, which contains a row for each trajectory, stationary period, and period without a signal for an object The geometry column from the subtrack table, which contains the trajectories, can require large amounts of space: You can fragment the geometry column among multiple storage spaces Index on the primary keys of the subtrack table Index on the end time of the trajectories in the subtrack table R-tree index on the trajectories in the geometry column Optional functional index on the instance ID of the time series This index can speed processing during spatiotemporal search queries © 2016 IBM Corporation

Spatiotemporal Indexing Parameters (1)
Defined as a BSON document: The parameters define how to configure spatiotemporal data and the storage spaces and extent sizes for subtrack tables and their indexes Syntax of parameters .-, V | >>---+-"--averageMovingGPSRate--"--:--seconds >< +-"--minStationaryInterval--"--:--seconds +-"--maxStationaryDistance--"--:--meters +-"--minNoDataInterval--"--:--seconds +-"--maxGPSTimeIntervalPerTrajectory--"--:--seconds +-"--maxMovingTrajectoryArea--"--:--square_meters +-"--position--"--:--[--longitude--,--latitude--] +-"--unitOfMeasure--"--:--"--meter--" +-"--maxNearestCount--"--:--rows +-"--SRID--"--: | .-, | | V | | +-"--storage--"--:--[----+-"--subtrack--"--:--"--storage--" ] | +-"--subtrackGeometry--"--:--"--storage--"-+ | | +-"--subtrackPK--"--:--"--storage--" | | +-"--subtrackRT--"--:--"--storage--" | | +-"--subtrackET--"--:--"--storage--" | | '-"--functionalIndex--"--:--"--storage--"--' | | .-, | | V | | +-"--extent--"--:--[----+-"--subtrack--"--:--[--first--,--next--] ]-+ | +-"--subtrackPK--"--:--[--first--,--next--] | | +-"--subtrackRT--"--:--[--first--,--next--] | | +-"--subtrackET--"--:--[--first--,--next--] | | '-"--functionalIndex--"--:--[--first--,--next--]-' | +-"--RTParameters--"--:--"--Rtree_index_parameters--" +-"--functionalIndexName--"--:--"--func_index_name--" '-"--transactionControl--"--: ' '-operations-' averageMovingGPSRate How often a position reading is generated for a moving object. The seconds value is an integer that represents the number of seconds between readings. Default is 60. minStationaryInterval How long an object must be in the same position to be considered stationary. The seconds value is an integer that represents the number of seconds before stationary status. Must be greater than the value of the averageMovingGPSRate field. Default is 300. maxStationaryDistance The maximum distance an object can move and still be considered to be stationary. The meters value is a float number greater than or equal to 0 that represents the maximum change in position for a stationary object. Default is 1. minNoDataInterval How long an object has no readings to be in a no signal or an interrupted signal state. The seconds value is an integer that represents the number of seconds before no signal or interrupted signal status. Must be greater than the value of the minStationaryInterval field. Default is 600. maxGPSTimeIntervalPerTrajectory The maximum amount of time for the trajectory of a moving object. The seconds value is an integer that represents the maximum number of seconds for a trajectory. Default is 600. maxMovingTrajectoryArea The maximum area of the bounding box around a trajectory. The square_meters value is a float number:0.0 = Default. No area limit. 1.0 or greater = The square meters of the bounding box around the trajectory. position A string array that identifies the sources of the longitude and latitude values. You can specify two BSON paths that start with the same BSON column name, or two FLOAT column names. The longitude value is the column name or the BSON path for the longitude data. Default is the second column, which must be of type FLOAT, in the TimeSeries subtype. The latitude value is the column name or the BSON path for the latitude data. Default is the third column, which must be of type FLOAT, in the TimeSeries subtype. For example, your TimeSeries subtype the following structure: CREATE ROW TYPE mytsrow( tstamp DATETIME YEAR TO FRACTION(5), temp FLOAT, data BSON); The BSON column has a document with this structure: {"sensor":{"position":{"lat":value,"long":value}}}. You set the position field to: "position": ["data.sensor.position.long", "data.sensor.position.lat"]. For example, your TimeSeries subtype has the following structure:CREATE ROW TYPE mytsrow( tstamp DATETIME YEAR TO FRACTION(5), temp FLOAT, gpslat FLOAT, gpslong FLOAT); You set the position field to: "position": ["gpslong","gpslat"]. unitOfMeasure The linear units of measure for trajectories. The value must be meters. maxNearestCount The count value is an integer that represents the default maximum number of rows to return from the STS_GetLocNearest function. Default is 10. You can override this value when you run the STS_GetLocNearest function. SRID The spatial reference identifier for trajectory objects. Must be storage Storage clauses for the subtrack tables and their associated indexes. Default is no storage clauses. The storage clauses require the syntax of the IN clause or the FRAGMENT BY clause of the CREATE TABLE and CREATE INDEX statements. See Storage options for tables and Storage options for indexes.subtrack The storage value is the storage clause for the subtrack tables. subtrackGeometry The storage value is the storage clause for the geometry columns in the subtrack tables. subtrackPK The storage value is the storage clause for the primary key indexes on the subtrack tables. subtrackRT The storage value is the storage clause for R-tree indexes on the subtrack tables. The storage spaces for R-tree indexes must all have the same page size. subtrackET The storage value is the storage clause for instance ID and end time indexes on the subtrack tables. functionalIndex The storage value is the storage clause for functional indexes on the time series instance IDs. The functionalIndexName parameter must be set. extent Extent size clauses for the subtrack tables and their associated indexes. Default is no extent clauses. The extent size clauses require the syntax of the EXTENT SIZE options of the CREATE TABLE and CREATE INDEX statements. See Extent size options for tables and Extent size options for indexes.subtrack The [first,next] integer values are the first and next extent sizes for the subtrack tables. subtrackPK The [first,next] integer values are the first and next extent sizes for the primary key indexes on the subtrack tables. subtrackRT The [first,next] integer values are the first and next extent sizes for R-tree indexes on the subtrack tables. subtrackET The [first,next] integer values are the first and next extent sizes for instance ID and end time indexes on the subtrack tables. functionalIndex The [first,next] integer values are the first and next extent sizes for functional indexes on the time series instance IDs. The functionalIndexName parameter must be set. RTParameters The Rtree_index_parameters value is a string that represents R-tree index parameters. Default is no R-tree index parameters. See R-tree index parameters. functionalIndexName The func_index_name value is a string that represents the name of the functional index on the time series IDs. A functional index on the time series instance IDs can speed processing. If you specify a name, the functional index is created. Default is no functional index. transactionControl An integer that specifies how to handle transactions for the Scheduler task and the STS_SubtrackCreate, STS_SubtrackDestroy, STS_SubtrackBuild, STS_SubtrackUpdate, and STS_SubtrackAlterProcessing subtrack processing functions:-1 = An explicit transaction is automatically created. Default for the Scheduler task. 0 = You must create an explicit transaction when you run subtrack processing functions. Default for subtrack processing functions. positive integer = An explicit transaction is automatically created that processes the specified number of time series values. This option can prevent long transaction failures when you index thousands or millions of time series values from the base table. Default parameters The following document represents the default parameters document: { "averageMovingGPSRate":60, "minStationaryInterval":300, "maxStationaryDistance":1, "minNoDataInterval":600, "maxGPSTimeIntervalPerTrajectory":900, "maxMovingTrajectoryArea":0.0, "unitOfMeasure":"meter", "SRID":4326, "transactionControl":0 } The default values for the storage and extent parameters are to omit storage and extent clauses from the CREATE TABLE and CREATE INDEX statements. If you omit storage and extent clauses, the default storage spaces and extent sizes for the database are used. By default the R-tree index parameters are omitted from the CREATE INDEX statement for the R-tree index. By default, the functional index on the time series instance ID is not created. When you set the parameters with the STS_SubtrackCreate or STS_SetDefaultParameters function, you specify only the parameters with non-default values. © 2016 IBM Corporation

averageMovingGPSRate How often a position reading is generated for a moving object seconds is an integer between ; the number of seconds between readings. Default is 60 minStationaryInterval How long an object must be in the same position to be considered stationary seconds is an integer between ; number of seconds before stationary status Must be greater than the value of the averageMovingGPSRate field. Default is 300 maxStationaryDistance Maximum distance an object can move and still be considered to be stationary meters is a float number >= 0; represents the maximum change in position for a stationary object Default is 1 minNoDataInterval How long an object has no readings to be in a no signal/interrupted signal state seconds value is an integer ; represents the number of seconds before no signal/interrupted signal status Must be greater than the value of the minStationaryInterval field Default is 600 © 2016 IBM Corporation

maxGPSTimeIntervalPerTrajectory Maximum amount of time for the trajectory of a moving object seconds is an integer ; the max number of seconds for a trajectory Default is 600. maxMovingTrajectoryArea Maximum area of the bounding box around a trajectory The square_meters value is a float number: 0.0 = Default. No area limit. >= 1.0 = The square meters of the bounding box around the trajectory position A string array that identifies the sources of the longitude and latitude values Specify two BSON paths that start with the same BSON column name, or two FLOAT column names. longitude value is the column name or the BSON path for the longitude data. Default is the second column, which must be of type FLOAT, in the TimeSeries subtype. latitude value is the column name or the BSON path for the latitude data. Default is the third column, which must be of type FLOAT, in the TimeSeries subtype. © 2016 IBM Corporation

For example, your TimeSeries subtype the following structure: CREATE ROW TYPE mytsrow( tstamp DATETIME YEAR TO FRACTION(5), temp FLOAT, data BSON); The BSON column has a document with this structure: {"sensor":{"position":{"lat":value,"long":value}}}. You set the position field to: "position": ["data.sensor.position.long", "data.sensor.position.lat"]. For example, your TimeSeries subtype has the following structure: CREATE ROW TYPE mytsrow( tstamp DATETIME YEAR TO FRACTION(5), temp FLOAT, gpslat FLOAT, gpslong FLOAT); "position": ["gpslong","gpslat"]. © 2016 IBM Corporation

unitOfMeasure The linear units of measure for trajectories. The value must be meters. maxNearestCount The count value is an integer that represents the default maximum number of rows to return from the STS_GetLocNearest function. Default is 10. You can override this value when you run the STS_GetLocNearest function. SRID The spatial reference identifier for trajectory objects. Must be 4326. © 2016 IBM Corporation

storage Storage clauses for the subtrack tables and their associated indexes. Default is no storage clauses. The storage clauses require the syntax of the IN clause or the FRAGMENT BY clause of the CREATE TABLE and CREATE INDEX statements. subtrack The storage value is the storage clause for the subtrack tables. subtrackgeometry The storage value is the storage clause for the subtrack tables geometry columns subtrackpk The storage value is the storage clause for the subtrack tables primary key indexes. subtrackrt The storage value is the storage clause for the subtrack tables R-tree indexes. The storage spaces for R-tree indexes must all have the same page size. subtracket The storage value is the storage clause for instance ID and end time indexes on the subtrack tables. functionalIndex The storage value is the storage clause for functional indexes on the time series instance IDs. The functionalIndexName parameter must be set. See Storage options for tables and Storage options for indexes. © 2016 IBM Corporation

extent Extent size clauses for the subtrack tables and their associated indexes. Default is no extent clauses. The extent size clauses require the syntax of the EXTENT SIZE options of the CREATE TABLE and CREATE INDEX statements.. subtrack The [first,next] integer values are the first / next extent sizes for the subtrack tables. subtrackPK The [first,next] integer values are the first / next extent sizes for the primary key indexes on the subtrack tables. subtrackRT The [first,next] integer values are the first / next extent sizes for R-tree indexes on the subtrack tables. subtrackET The [first,next] integer values are the first / next extent sizes for instance ID and end time indexes on the subtrack tables. functionalIndex The [first,next] integer values are the first / next extent sizes for functional indexes on the time series instance IDs. The functionalIndexName parameter must be set. See Extent size options for tables and Extent size options for indexes © 2016 IBM Corporation

RTParameters rtree_index_parameters is a string that represents R-tree index parameters. Default is no R-tree index parameters. functionalIndexName func_index_name string; represents the time series IDs functional index name A functional index on the time series instance IDs can speed processing. If a name is specified, the functional index is created. Default is no functional index. transactionControl Integer specifying how to handle transactions for Scheduler task, STS_SubtrackCreate, STS_SubtrackDestroy, STS_SubtrackBuild, STS_SubtrackUpdate, STS_SubtrackAlterProcessing subtrack processing functions: -1 = An explicit transaction is automatically created. Default for the Scheduler task. 0 = Must create an explicit transaction when subtrack processing functions run. Default for subtrack processing functions. > 0 = An explicit transaction is automatically created that processes the specified number of time series values; option can prevent long transaction failures when you index thousands or millions of time series values from the base table. See R-tree index parameters © 2016 IBM Corporation

Default parameters The following JSON document represents the default parameters: { "averageMovingGPSRate":60, "minStationaryInterval":300, "maxStationaryDistance":1, "minNoDataInterval":600, "maxGPSTimeIntervalPerTrajectory":900, "maxMovingTrajectoryArea":0.0, "unitOfMeasure":"meter", "SRID":4326, "transactionControl":0 } The default values for the storage and extent parameters are to omit storage and extent clauses from the CREATE TABLE and CREATE INDEX statements. If omitted, the default storage spaces and extent sizes for the database are used. © 2016 IBM Corporation

By default the R-tree index parameters are omitted from the CREATE INDEX statement for the R-tree index. By default, the functional index on the time series instance ID is not created. When you set the parameters with the STS_SubtrackCreate or STS_SetDefaultParameters function, you specify only the parameters with non-default values. © 2016 IBM Corporation

Starting Spatiotemporal Indexing (1)
Run the STS_SubtrackCreate function for the time series column: TimeSeries, Spatial, and R-tree index extensions pre-registered in the database. A time series table must exist. To start spatiotemporal indexing: Prepare storage spaces for the spatiotemporal data. Optional: With multiple CPU virtual processors available, Set the PRELOAD_DLL_FILE onconfig parameter to the path for the spatiotemporal shared library file in the onconfig file Restart the database server: PRELOAD_DLL_FILE $INFORMIXDIR/extend/sts.version/sts.bld The version is the version number of the spatiotemporal search extension. Set default parameters for configuring spatiotemporal data and storage by running the STS_SetDefaultParameters function. Run the STS_SubtrackCreate function for the time series. A subtrack table and spatiotemporal search system tables are created. If Scheduler tasks are configured, the subtrack table is populated and indexed. © 2016 IBM Corporation

Starting Spatiotemporal Indexing (2)
If you did not configure a Scheduler task with the STS_SubtrackCreate function, run the STS_SubtrackBuild function to populate the subtrack table and index the initial set of data. The tables used for Spatiotemporal indexing and data are defined in Appendix B. © 2016 IBM Corporation

STS_SetDefaultParameters Function (1)
Sets the default parameters for building subtrack tables. Syntax STS_SetDefaultParameters( parameters BSON) returns INTEGER parameters A BSON document that contains parameters for building the subtrack table and its associated indexes. Usage Use the STS_SetDefaultParameters function to create a default BSON parameters document that is used when you omit the BSON parameters document from the STS_SubtrackCreate function. The STS_SetDefaultParameters function inserts the BSON parameters document into the STS_DefaultParametersTable table. The default BSON parameters document does not affect any existing subtrack definitions. For the syntax of the parameters, see Spatiotemporal indexing parameters © 2016 IBM Corporation

To update the existing BSON parameters document, run the function STS_SetDefaultParameters with a new BSON parameters document. To remove the BSON parameters document, specify NULL in the STS_SetDefaultParameters function. Returns 0 = Parameters are stored in the STS_DefaultParametersTable. An exception = An error. For the syntax of the parameters, see Spatiotemporal indexing parameters © 2016 IBM Corporation

The following example creates a default properties document in the STS_DefaultParametersTable table: EXECUTE FUNCTION STS_SetDefaultParameters( '{ "averageMovingGPSRate":10, "minStationaryInterval":300, "maxStationaryDistance":1, "minNoDataInterval":900, "maxGPSTimeIntervalPerTrajectory":1800, "maxMovingTrajectoryArea": }'::JSON::BSON ); Readings for moving objects are taken at an average of every 10 seconds. Objects must not move more that 1 meter in 5 minutes to be considered stationary. If data is missing for an object for 15 minutes, the object has an interrupted signal status. Each trajectory is limited to 30 minutes and a bounding box area of m2. For the syntax of the parameters, see Spatiotemporal indexing parameters © 2016 IBM Corporation

STS_SubtrackCreate Function (1)
Creates the subtrack table for the specified time series and can start a Scheduler task to build the spatiotemporal index and periodically index new spatiotemporal data. Syntax STS_SubtrackCreate( base_table_name VARCHAR(128), ts_column_name VARCHAR(128), subtrack_name VARCHAR(128)) returns VARCHAR(128) subtrack_name VARCHAR(128), flags INTEGER DEFAULT 1) returns VARCHAR(128) flags INTEGER DEFAULT 1, parameters BSON) returns VARCHAR(128) © 2016 IBM Corporation

Syntax (cont’d) STS_SubtrackCreate( base_table_name VARCHAR(128), ts_column_name VARCHAR(128), subtrack_name VARCHAR(128), flags INTEGER DEFAULT 1, parameters BSON, ts_data_first_timestamp DATETIME HOUR TO SECOND DEFAULT NULL, ts_data_lag_to_current INTERVAL DAY TO SECOND DEFAULT NULL, task_nschsessions INTEGER DEFAULT 1, task_frequency INTERVAL DAY TO SECOND DEFAULT NULL DEFAULT "0 01:00:00", task_start_time DATETIME HOUR TO SECOND DEFAULT NULL, task_data_interval_to_process INTERVAL DAY TO SECOND DEFAULT NULL) returns VARCHAR(128) © 2016 IBM Corporation

base_table_name The name of the time series table. ts_column_name The name of the time series column in the time series table. subtrack_name The name to give the resulting the subtrack table for this time series. Must be unique in the database. Maximum length is 124 bytes. flags (Optional) Whether to create a Scheduler task to automatically index new data: 1 = Default. Create a Scheduler task. 2 = Do not create a Scheduler task. parameters (Optional) A BSON document that contains parameters for building the subtrack. If you omit the parameters document, the parameter values that are in the STS_DefaultParametersTable table are used. If the STS_DefaultParametersTable table is empty, the default parameters document is used. For the syntax of the parameters document, see Spatiotemporal indexing parameters. © 2016 IBM Corporation

ts_data_first_timestamp (Optional) The first time stamp in the time series to index. Default is the origin of the time series. ts_data_lag_to_current (Optional) The time interval before the current time to avoid indexing. Default is the time stamp of the latest element in the time series. task_nschsessions (Optional) The number of Scheduler tasks to start to update the index in parallel. Default is 1. task_frequency (Optional) How frequently to index new data with the Scheduler task. Default is every hour. task_start_time (Optional) The first time to start the Schedule task. Default is NULL, the task starts when the STS_SubtrackCreate function is run. task_data_interval_to_process (Optional) The time series time interval to process each time that the Scheduler task is run. If this value != task_frequency parameter value, the index might be incomplete. Default is that new data is subject to the ts_data_lag_to_current setting. © 2016 IBM Corporation

The STS_SubtrackCreate function starts the indexing process by creating the subtrack table for the time series and optionally starting a Scheduler task to index the data. If the value of the flags parameter is set to 2 and there is not a Scheduler task created, run the STS_SubtrackBuild function to start indexing or configure indexing with the time series loader functions. The parameters ts_data_first_timestamp and ts_data_lag_to_current control the data time range to index for all indexing methods. You can change the indexing time range by running the functions STS_SubtrackAlterFirstTimeStamp and STS_SubtrackAlterLagToCurrent. © 2016 IBM Corporation

If the flags parameter is set to 1, a Scheduler task is created to start indexing the data The Scheduler task, which has a prefix name of autosts, starts at the specified time, indexes the initial set of data, and periodically indexes new data The task prints messages in the database server message log when indexing starts and completes Indexing can be faster by starting multiple Scheduler task sessions You can create, remove, or change a Scheduler task by running the STS_SubtrackAlterProcessing function. © 2016 IBM Corporation

The Scheduler task is started at the time that is specified by the task_start_time parameter. First run of the task processes the data in the time interval defined by the value of the ts_data_first_timestamp parameter to the time calculated by subtracting the value of the ts_data_lag_to_current parameter from current time. Subsequent runs of the task start based on the value of the task_frequency parameter and index the data between the last end time and the earlier of the following times: The last end time plus the value of the task_data_interval_to_process parameter The current time minus the value of the ts_data_lag_to_current parameter Any data inserted with timepoints that are earlier than the last end time are not indexed If you run the Scheduler task the first time on an empty time series, the recorded last end time is the current time minus the value of the ts_data_lag_to_current parameter Earlier timepoints are not indexed. Returns A string = The name of the subtrack table. An exception = An error. © 2016 IBM Corporation

STS_SubtrackCreate Function – Example - Defaults
The following statement is run at :00:00 creates the t_vehicle_subtrack subtrack table and starts a Scheduler task: BEGIN WORK; Started transaction. EXECUTE FUNCTION STS_SubtrackCreate('t_vehicle', 'ts_track', 't_vehicle_subtrack'); (expression) t_vehicle_subtrack 1 row(s) retrieved. COMMIT WORK; Data committed. Task runs for the first time at 08:00:00, processes the time series data with timepoints between time series origin and :00:00. The task takes about 30 minutes to index the data. The task runs again at 09:00:00 and indexes data with timepoints between :00:00 and :00:00. Any data with timepoints earlier than :00:00 that was inserted after the first task was run is not indexed. © 2016 IBM Corporation

STS_SubtrackCreate Function – Example - Custom
Below creates the ts_vehicle_subtrack table and sets custom values to configure trajectories, but does not create a Scheduler task: BEGIN WORK; EXECUTE FUNCTION STS_SubtrackCreate('t_vehicle', 'ts_track', 'ts_vehicle_subtrack', 2, '{ "averageMovingGPSRate":10, "minStationaryInterval":300, "maxStationaryDistance":1, "minNoDataInterval":900, "maxGPSTimeIntervalPerTrajectory :1800, "maxMovingTrajectoryArea":128000, "unitOfMeasure":"meter", "SRID":4326, "storage":{ "subtrack":"FRAGMENT BY ROUND ROBIN in datadbs_1,datadbs_2 ", "subtrackGeometry":"IN (sbspace1,sbspace2)", "subtrackPK":"in indexspace1", "subtrackET":"in indexspace1", "subtrackRT":"fragment by expression partition part1 ( instance_id < ) in indexdbs, partition part2 ( instance_id < ) in indexdbs, partition part3 ( instance_id < ) in indexdbs, partition part4 remainder in indexdbs" }, "extent":{ "subtrack":[12800,6400], "subtrackPK":[6400,3200], "subtrackET":[6400,3200], "subtrackRT":[2000,4000] } }'::json::bson); COMMIT WORK; © 2016 IBM Corporation

Readings for moving objects are taken at an average of every 10 seconds. Objects cannot move > 1 meter in 5 minutes to be considered stationary. If object data is missing for 15 minutes, object has an interrupted signal status. Each trajectory is limited to 30 minutes and a bounding box area of m2. The subtrack tables and their associated indexes have storage clauses and extent sizes. The subtrack table remains empty until you run the STS_SubtrackBuild function to build trajectories, or run the STS_SubtrackAlterProcessing function to start a Scheduler task. © 2016 IBM Corporation

Set a custom Scheduler task definition. The following statement creates the ts_vehicle_subtrack table and sets custom values for the Scheduler task: BEGIN WORK; EXECUTE FUNCTION STS_SubtrackSubtrackCreate('t_vehicle', 'ts_track', 't_vehicle_subtrack', 1, NULL, ' :00:00', '0 12:00:00', 3, '0 02:00:00', '12:00:00', '1 00:00:00'); COMMIT WORK; The first time stamp is set to the beginning of May 2014. The indexing lag time is set to 12 hours. Three Scheduler tasks are started that run every two hours, first start at 12:00, and process one day of data. © 2016 IBM Corporation

STS_Subtrack_Build Function
The STS_SubtrackBuild function indexes spatiotemporal data for the specified subtrack table. Syntax STS_SubtrackBuild( subtrack_name VARCHAR(128), flags INTEGER DEFAULT 1) returns BIGINT subtrack_name The name of the subtrack table. Must exist. flags The scope of the indexing: 1 = Default. Incrementally build the index 2 = Rebuild the whole index © 2016 IBM Corporation

STS_Subtrack_Build Function - Usage
Populates the specified subtrack table. Subtrack table must exist previously by running STS_SubtrackCreate function. The indexing time range is set by the values of the ts_data_first_timestamp and ts_data_lag_to_current parameters, as set in the STS_SubtrackCreate function, or as reset by the STS_SubtrackAlterFirstTimeStamp and STS_SubtrackAlterLagToCurrent functions. Set the flags parameter to 1: Indexing begins after the end time of the latest entry in the subtrack table. If the subtrack table is empty, indexing begins from the value of the ts_data_first_timestamp parameter and continues until the time specified by the ts_data_lag_to_current parameter. Set the flags parameter to 2: Any existing data in the subtrack table is deleted, and then the every time series element is indexed from the value of the ts_data_first_timestamp parameter until the time specified by the ts_data_lag_to_current parameter. Rebuilding the subtrack table can be useful if removing or updating existing data or adding data earlier than the latest time stamp. © 2016 IBM Corporation

STS_Subtrack_Build Function – Usage & Examples
Returns An integer = The number of time series values processed. An exception = An error. Following rebuilds the whole ts_vehicle_subtrack subtrack table: BEGIN WORK; EXECUTE FUNCTION STS_SubtrackBuild('ts_vehicle_subtrack', 2); COMMIT WORK; Following updates the subtrack table with trajectories for new data: EXECUTE FUNCTION STS_SubtrackBuild('ts_vehicle_subtrack', 1); COMMIT WORK; © 2016 IBM Corporation

Hertz Data Enhancement for TimeSeries
Enter whole-second blocks of hertz records into a time series out of chronological order. If a time series is missing data for an entire second at sometime in the past, you can enter the data. However, you must enter subsecond elements within a second in chronological order. Hertz data can now be stored in rolling window containers. © 2016 IBM Corporation

TimeSeries Virtual Tables Longer Fragmentation Lengths
The fragmentation scheme for virtual tables is adapted from the fragmentation scheme of the base table Sometimes, the resulting virtual table creation statement can be much longer the maximum length of an SQL statement To remedy this, specify one of the two new fragmentation flags in the TSVTMode parameter of the TSCreateVirtualTab procedure. If the base table fragmentation clause has expressions mapping to a single fragment and there is no REMAINDER clause Use the fragment_verbatim (value of 65536) flag Virtual table creation statement uses the same fragmentation as the base table. If the base table fragmentation clause has ambiguous expressions or a REMAINDER clause with a CASE statement Use the fragment_with_case (value of ) flag Virtual table creation statement not much longer than that of the base table. This fragmentation setting can occasionally result in unexpected query plans, such as sequential scans. © 2016 IBM Corporation

TimeSeries Aggregation Queries
The TimeSeries AggregateBy function can be also used to perform aggregations within the Mongo aggregation framework; this is done with a $group by a $calendar object. Currently supported aggregation operators for timeseries data are: $sum, $avg, $min, $max, $median, $first, $last, $nth The AggregateBy function aggregates the values in a time series using a new time interval specified by providing a calendar Can be used to convert a time series with a small interval to a larger interval; for instance, to produce a weekly from a daily time series. If you supply the optional start and end DATETIME parameters, just that part of the time series is aggregated to the new time interval. © 2016 IBM Corporation

TimeSeries Aggregation Queries
Syntax AggregateBy( agg_express lvarchar, cal_name lvarchar, ts TimeSeries flags integer default 0 start datetime year to fraction(5) default NULL, end datetime year to fraction(5) default NULL ) returns TimeSeries; agg_express A comma-separated list of these SQL aggregate operators: MIN, MAX, MEDIAN, SUM, AVG, FIRST, LAST, or Nth. MIN, MAX, MEDIAN, SUM, and AVG expressions operate only on numeric columns. cal_name The name of a calendar that defines the aggregation period. ts The time series to be aggregated. flags (optional) Determines how data points in off periods of calendars are handled during aggregation. © 2016 IBM Corporation

AggregateBy (1) The AggregateBy function converts the input time series to a regular time series with a calendar given by the cal_name argument. The agg_express expressions operate on a column of the input time series, which is specified by one of the following column identifiers: $colname colname is the column name to aggregate in the TimeSeries data type. If the column name is high, the column identifier is $high. $colnumber colnumber is the column position to aggregate in the TimeSeries data type. For example if the column number is 1, the column identifier is $1. © 2016 IBM Corporation

AggregateBy (2) $bson_field_name
The bson_field_name is the name of a field in at least one BSON document in the BSON column in the TimeSeries data type. For example, if the field name is v1, the column identifier is $v1. If the BSON field name is the same as another column in the TimeSeries data type, you must qualify the field name as follows: $colname.bson_field_name For example, if the BSON column name is b_data and the field name is v1, the column identifier is $b_data.v1 or more generally: $colnumber.bson_field_name For example, if the BSON column number is 1 and the field name is v1, the column identifier is $1.v1. © 2016 IBM Corporation

AggregateBy (3) Cast the results of the AggregateBy function on a BSON field to a TimeSeries data type that has the appropriate type of columns for the result of the expression. The Nth expression returns the value of a column for the specified aggregation period, using the following syntax: Nth($col, n) $col The column identifier. n A positive or negative number indicating the TimeSeries row position within the aggregation period. Positive values of n begin at the first row in the aggregation period; therefore: Nth($col, 1) is equivalent to FIRST($col). Negative values of n begin with the last row in the aggregation period; therefore: Nth($col, -1) is equivalent to LAST($col). If an aggregation period does not have a value for the nth row, then the Nth function returns a null value for that period. The Nth function is more efficient for positive than negative values of the n argument. © 2016 IBM Corporation

AggregateBy (4) Aggregation time period is denoted by its start date and time. The origin of the aggregated output time series is the first period on or before the origin of the input time series. Each output period is the aggregation of all input periods from the start of the output period up to, but not including, the start of the next output period. For instance, suppose you want to aggregate a daily time series that starts on Tuesday, Jan. 4, 2011, to a weekly time series. The input calendar, named “days,” starts at 12:00 a.m., and the output calendar, named “weeks,” starts at 12:00 a.m., on Monday. The first output time is 00:00 Jan. 3, 2011; it is the aggregation of all input values from the input origin, Jan. 4, 2011, to 23:59: Jan. 9, 2011. The second output time is 00:00 Jan. 10, 2011; it is the aggregation of all input values from 00:00 Jan 10, 2011 to 23:59: Jan. 16, 2011. © 2016 IBM Corporation

AggregateBy (5) The AggregateBy function is used to aggregate from a fine-grained regular time series to a coarser-grained one. The following scenarios are also supported: Converting from a regular time series to a time series with a calendar of the same granularity. In this case, AggregateBy shifts the times back to accommodate differences in the calendar start times: for example, 00:00 from 8:00. Elements can be removed or null elements added to accommodate differences in the calendar on/off pattern. Regular time series conversion to one with a calendar of finer granularity. In this case, AggregateBy replicates values. Irregular input time series. Because the granularity of an irregular time series does not depend on the granularity of the calendar, this case is treated like aggregation from a fine-grained time series to a coarser-grained one. This type of aggregation always produces a regular time series. © 2016 IBM Corporation

AggregateBy – flags Argument Values (1)
flags argument determines how data points in off calendar periods are handled during aggregation and how hidden elements are managed with the following values: 0 (Default) Data in off periods is aggregated with the next output period. 1 Data in off periods is aggregated with the previous output period. 2 Indicates that the scan runs with the TS_SCAN_HIDDEN flag set (hidden elements are returned). 4 Indicates that the scan runs with the TS_SCAN_SKIP_HIDDEN flag set (hidden elements are not returned). Example, consider an input time series that has a daily calendar with no off days: It has data from weekdays and weekends. If you aggregate this data by a business-day calendar (5 days on, 2 days off, starting on a Monday), A flags argument of 0 causes weekend data to be aggregated with the next Monday's data, A flags argument of 1 causes weekend data to be aggregated with the previous Friday's data. © 2016 IBM Corporation

AggregateBy – flags Argument Values (2)
Consider a quarterly calendar defined as: 'startdate( :00: ), pattstart( :00: ), pattern({1 on, 2 off}, month' A calendar aggregates with either a flags value of 0 or no flags value: All input points up to, but not including, :00: are aggregated into the first output element. All points from :00: up to, but not including, :00: are aggregated into the second output element, and so on. If the flags argument is 1: All input points up to but not including :00: are aggregated into the first output element. All points from :00: up to, but not including, :00: are aggregated into the second output element, and so on. The AggregateBy clause might look like this: AggregateBy('max($high)', 'quarterlycal', ts, 1); Returns The aggregated time series, which is always regular, if you are aggregating to a new time interval. The resulting time series has a time stamp column plus one column for each expression in the list. © 2016 IBM Corporation

AggregateBy - Examples
The following query aggregates the daily_stocks time series to a weekly time series: insert into daily_stocks( stock_id, stock_name, stock_data) select stock_id, stock_name, AggregateBy( 'max($high), min($low),last($final),sum($vol)', 'weekcal', stock_data)::TimeSeries(stock_bar) from daily_stocks; The following query clause selects the second price from each week: AggregateBy( 'Nth($price, 2)', 'weekly', ts) This query clause selects the second to the last price from each week: AggregateBy( 'Nth($price, -2)', 'weekly', ts) © 2016 IBM Corporation

AggregateBy – BSON Example
A TimeSeries row type contains an INTEGER column that is named v1 and the BSON column contains a field that is also named v1. CREATE ROW TYPE rb(timestamp datetime year to fraction(5), data bson, v1 int); INSERT INTO tj VALUES(1,'origin( :00: ), calendar(ts_15min), container(kontainer),threshold(0), regular,[({"v1":99},20)]'); The following statement creates a TimeSeries data type to hold the results of the aggregation on the BSON field in an INTEGER column: CREATE ROW TYPE outrow(timestamp datetime year to fraction(5), x int); If a column and a BSON field have the same name, the column takes precedence. © 2016 IBM Corporation

AggregateBy – BSON Example
Following returns the maximum value from the v1 INTEGER column: SELECT AggregateBy('max($v1)','ts_1year',tsdata,0 " :00: "::datetime year to fraction(5), " :00: "::datetime year to fraction(5)) FROM tj; Following two equivalent statements return the maximum value from the v1 field in the data BSON column; column 1 in the TimeSeries row type: SELECT AggregateBy('max($data.v1)','ts_1year',tsdata,0 " :00: "::datetime year to fraction(5), " :00: "::datetime year to fraction(5)) ::timeseries(outrow) FROM tj; SELECT AggregateBy('max($1.v1)','ts_1year',tsdata,0 " :00: "::datetime year to fraction(5), " :00: "::datetime year to fraction(5)) ::timeseries(outrow) FROM tj; The aggregated time series that is returned has the TimeSeries data type outrow. If you do not cast the result to a row type that has appropriate columns for the results, the statement fails. © 2016 IBM Corporation

JSON Spatial Data Improvements
Display spatial data in JSON-based applications by converting a geometry to a BSON document in GeoJSON format. Execute the SE_AsBSON function on a geometry to return a BSON document. Use SE_AsBSON() to retrieve spatial data from the server and send it to a client that displays data in GeoJSON format: SELECT SE_AsBSON(geomcol) FROM mytable Function takes an ST_Point, ST_LineString, ST_Polygon, ST_MultiPoint, ST_MultiLineString, or ST_MultiPolygon geometry and returns a BSON document in GeoJSON format. If the geometry value is empty, this function returns NULL. Example The point with the definition of '4326 point( )' is converted into the following BSON document in GeoJSON format: { "type": "Point", "coordinates": [ ,43.872] } © 2016 IBM Corporation

MQTT & JSON – Internet of Things (IoT) (1)
Load JSON documents with the MQTT protocol by defining a wire listener of type MQTT. The MQTT protocol is a light-weight messaging protocol that you can use to load data from devices or sensors: Use the MQTT protocol with Informix to publish data from sensors into a time series that contains a BSON column. © 2016 IBM Corporation

Informix supports the following operations for MQTT: CONNECT PUBLISH (equivalent to insert) DISCONNECT Configure an MQTT wire listener by setting the listener.type=mqtt parameter in the wire listener configuration file. From an MQTT client, you send PUBLISH packets to insert data. You can authenticate MQTT client users through the wire listener. Network Connections via TCP/IP or TLS and WebSocket; not UDP 1 The MQTT protocol requires an underlying transport that provides an ordered, lossless, stream of bytes from the Client to Server and Server to Client. The transport protocol used to carry MQTT 3.1 & is TCP/IP TCP ports 8883 (TLS) and 1883 (non TLS) communications respectively are used 1. Section 4.2 © 2016 IBM Corporation

MQTT & JSON – Connect & Publish
Connect (database_name.user_name) Include a Connect packet to identify the client user. If authentication is enabled in the MQTT wire listener with the authentication.enable=true setting, specify a user name and password. User name includes the database name in the following format: database_name.user_name. Example: connect to the database mydb as user joe with the password pass4joe: CONNECT(mydb.joe, pass4joe) Publish (topicName, { message } The Publish packet maps to the MongoDB insert or create command. The topicName field must identify the target database and table in the following format: database_name/table_name, The message field must be in JSON format. If you are inserting data into a relational table, the field names in the JSON documents must correspond to column names in the target table. The following example inserts a JSON document into the sensordata table in the mydb database: PUBLISH(mydb/sensordata, { "id": "sensor1234", "reading": 87.5}) © 2016 IBM Corporation

Prerequisites: Cannot presently create a time series through the MQTT wire listener Create a JSON time series with the REST API, the MongoDB API, or SQL statements TimeSeries row type consists of a time stamp and BSON columns Example: In SQL, with row type, accompanying table, and storage container with record insert for the data: CREATE ROW TYPE ts_data_j2( tstamp datetime year to fraction(5), reading BSON); CREATE TABLE IF NOT EXISTS tstable_j2( id INT NOT NULL PRIMARY KEY, ts timeseries(ts_data_j2) ) LOCK MODE ROW; EXECUTE PROCEDURE TSContainerCreate('container_j', 'dbspace1', 'ts_data_j2', 512, 512); INSERT INTO tstable_j2 VALUES(1, 'origin( :00: ), calendar(ts_15min), container(container_j), regular, threshold(0), []'); Create a virtual table with a JSON time series EXECUTE PROCEDURE TSCreateVirtualTab("sensordata", "tstable_j2"); © 2016 IBM Corporation

MongoDB 3.2 API Support Informix is compatiable with the MongoDB 3.2 API’s versions. C Driver Compatibility MongoDB C Driver C++ Driver Compatibility C++ version & legacy C#/.Net Driver Compatibility Versions 2.2 & 1.1.1 Java Driver Compatibility Version 3.2 Node.js Driver Compatibility Version 2.1.0 Perl Driver Compatibility Version 1.4.x & 1.2.x PHP Driver Compatibility PHPLIB mongodb-1.1 Python Driver Compatibility Version 3.2 Ruby Driver Compatibility Version 2.2 Scala Driver Compatibility Version 1.1 © 2016 IBM Corporation

IWA on Power8 Linux on Little Endian
Certified Not just limited to X86/64 servers anymore. Reported 26% faster © 2016 IBM Corporation

IWA on Power8 Linux on Little Endian
1/4th as many cores as the previous INTEL platforms and 60% faster, minimum. Previous platform is 100 PVU, power platform is 70 PVU. © 2016 IBM Corporation

Open Source Contributions
Informix Node.js driver update I want to use a native node.js driver for Informix database server and be able to download/install it through the Node.js package ecosystem (npm). In addition, I want to be able to use all the supported APIs from latest stable Version of node.js (v4.4.5 LTS) within my application. Informix to Spark streaming prototype: Performs distributed stream processing and advanced analytics on transactional data to gain real time insight for my business. Instead of batch processing: I need to stream the transactional data to a stream processing engine without disrupting or adding complexity to my transactional data which drives my business. I need a way for my operational (relational/NoSQL) database to stream the transactional data to an external distributed stream processing engine through a well-known/universally supported protocol like MQTT. © 2016 IBM Corporation

NOVALIDATE for Check Constraints & dbaccess history
The NOVALIDATE keyword prevents the database server from checking every row for referential integrity during ALTER TABLE ADD CONSTRAINT and SET CONSTRAINTS operations on foreign-key constraints. Can be used during whole database migrations (server to server) with new schema layouts during the suspend constraints phase just prior to data movement and after completing schema layout on target server. dbaccess now records SQL statement execution history. dbaccess –his stores_demo © 2016 IBM Corporation

Appendix A – Spatiotemporal Functions – STS_Init() (1)
The STS_Init () function creates internal tables and starts a Scheduler task that builds the initial spatiotemporal index, and then periodically indexes new spatiotemporal data. Syntax STS_Init(ts_tabname VARCHAR(128)) returns INTEGER STS_Init(ts_tabname VARCHAR(128) task_frequency INTERVAL DAY TO SECOND default "0 01:00:00", task_starttime DATETIME HOUR TO SECOND default NULL, ts_default_starttime DATETIME YEAR TO SECOND default " :00:00", ts_interval_to_process INTERVAL DAY TO SECOND default "0 01:00:00", ts_interval_to_avoid INTERVAL DAY TO SECOND default "1 00:00:00" ) returns INTEGER © 2016 IBM Corporation

ts_tabname The name of the time series table. task_frequency (optional) How frequently to index new data. Default is every hour. task_starttime (Optional) The first time to start the task. Default is NULL, which means to start the task when the STS_Init function is run. ts_default_starttime (Optional) The first time stamp in the time series from which to index. Default is :00:00. ts_interval_to_process (Optional) The time interval in the time series to process each time that the task is run. Default is one hour. Set to a value that takes less time to index than the task_frequency parameter. ts_interval_to_avoid (Optional) The indexing lag time. The time interval in the time series before the current time to avoid indexing. Default is one day. © 2016 IBM Corporation

Run STS_Init () to start the indexing process by creating internal spatiotemporal search tables and starting a Scheduler task for the specified table. The Scheduler task, which has a prefix of autosts, starts at the time specified by the task_starttime parameter, indexes the initial set of data, and periodically indexes new data. The task prints messages in the database server message log when indexing starts and completes. If spatiotemporal search indexing is already running for the specified table, run the STS_Init() to change the Scheduler task properties. The first run of the task processes the data in the time interval that is defined by the value of the ts_default_starttime parameter: ts_default_starttime = current_time - ts_interval_to_avoid © 2016 IBM Corporation 289

The end time of the processing interval is saved in the internal lasttime table. Subsequent runs of the task start based on the value of the task_frequency parameter and index the data between the last end time that is saved in the lasttime table and the earlier of the following times: The last end time plus the value of the ts_interval_to_process parameter The current time minus the value of the ts_interval_to_avoid parameter Any data that you insert with timepoints that are earlier than the last end time that is saved in the lasttime table are not indexed. If you run the task the first time on an empty time series, the recorded last end time is the current time minus the value of the parameter ts_interval_to_avoid. Any data that you insert with earlier timepoints are not indexed. Returns 0 or 1 - an integer that indicates the status of the function: 0 = The Scheduler task for spatiotemporal search indexing started. 1 = An error occurred. © 2016 IBM Corporation

Example The following statement is run at :00:00 (not shown) to start spatiotemporal search indexing on the T_Vehicle table: EXECUTE FUNCTION STS_Init('T_Vehicle'); The Scheduler task for T_Vehicle is created with default values The task runs for the first time at 08:00:00 and processes the time series data with timepoints between :00:00 and :00:00. The last end time of :00:00 is recorded in the lasttime table. The task takes about 30 minutes to index the data. The task runs again at 09:00:00 and indexes data with timepoints between :00:00 and :00:00. The last end time of :00:00 is recorded in the lasttime table. Any data with timepoints earlier than :00:00 that was inserted after the first task was run is not indexed. © 2016 IBM Corporation

Appendix A – STS_Cleanup() (1)
Stop spatiotemporal search indexing and drop internal tables. Syntax STS_Cleanup(ts_tabname VARCHAR(128)) returns INTEGER STS_Cleanup() returns INTEGER ts_tabname (Optional) - The name of the time series table. Usage Run with the ts_tabname parameter when you want to stop spatiotemporal indexing and drop the existing spatiotemporal search tables for the specified time series table: When the spatiotemporal search tables becomes large, you can drop them and then restart spatiotemporal search indexing with a more recent start time. Run without a parameter to stop spatiotemporal indexing and drop the existing spatiotemporal search tables for the current database. Returns An integer that indicates the status of the function: 0 = Spatiotemporal search indexing was removed. 1 = An error occurred. © 2016 IBM Corporation

Appendix A – STS_Cleanup() (2)
Example: Stop indexing and drop index tables for a table The following statement stops spatiotemporal search indexing and deletes the internal tables for the time series table T_Vehicle: EXECUTE FUNCTION STS_Cleanup('T_Vehicle'); Stop indexing and drop index tables for a database The following statement stops spatiotemporal search indexing and deletes the internal tables for the current database: EXECUTE FUNCTION STS_Cleanup(); © 2016 IBM Corporation

Appendix A – STS_GetPosition() (1)
Find the position of an object at a specific time: Syntax STS_GetPosition(ts TimeSeries, tstamp DATETIME YEAR TO FRACTION(5)) returns LVARCHAR ts The time series. tstamp The time stamp to query. © 2016 IBM Corporation

Appendix A – STS_GetPosition() (2)
To identify which object to track is defined in the WHERE clause of the query. Returns An LVARCHAR string that represents the position of the object. The string includes the spatial reference ID (SRID 4326) and a point that consists of a longitude value and a latitude value. NULL, if nothing found. Example The following query returns the position of the vehicle 1 at :34:06: SELECT STS_GetPosition(ts_track, ' :34:06') FROM T_Vehicle WHERE modid='1'; (expression) point( ) © 2016 IBM Corporation

Appendix A – STS_GetLastPosition() (1)
Find the most recent position of any object in the time series: Syntax STS_GetPosition(ts TimeSeries, tstamp DATETIME YEAR TO FRACTION(5)) returns LVARCHAR ts The time series. tstamp The time stamp to query. © 2016 IBM Corporation

Appendix A – STS_GetLastPosition() (2)
Run STS_GetPosition() to find where a moving object was at a specific time. To identify which object to track is in the WHERE clause of the query. Returns: An LVARCHAR string that represents the position of the object. The string includes the spatial reference ID (4326) and a point that consists of a longitude value and a latitude value. Or NULL, if nothing found. Example: The following query returns the position of the vehicle 2 at :38:06: SELECT STS_GetPosition(ts_track, ' :38:06') FROM T_Vehicle WHERE modid=‘2'; (expression) point( ) © 2016 IBM Corporation 297

Appendix A - STS_GetFirstTimeByPoint() (1)
Find the first time in a time range when an object is near a position Syntax STS_GetFirstTimeByPoint(ts_tabname LVARCHAR, obj_id LVARCHAR, ts TimeSeries, starttime DATETIME YEAR TO FRACTION(5), endtime DATETIME YEAR TO FRACTION(5), geometry LVARCHAR, max_distance REAL) returns DATETIME obj_id LVARCHAR, ts TimeSeries, starttime DATETIME YEAR TO FRACTION(5), endtime DATETIME YEAR TO FRACTION(5), geometry LVARCHAR, max_distance REAL, uom LVARCHAR) © 2016 IBM Corporation

Syntax (cont’d) ts_tabname The name of the time series table. obj_id The ID of the object. Must be a value from the primary key column of the time series table. Can be the name of the column that stores the object IDs if the WHERE clause specifies a specific object ID. ts The name of the TimeSeries data type. starttime The start of the time range. Can be NULL. endtime The end of the time range. © 2016 IBM Corporation

Syntax (cont’d) geometry The geometry at the center of the region of interest. Can be an ST_Point, ST_MultiPoint, ST_LineString, ST_MultiLineString, ST_Polygon, or ST_MultiPolygon. Must use the SRID 4326. max_distance The distance from the geometry that defines the border of the region of interest. The unit of measure is specified by the uom parameter. uom (Optional) The unit of measure for the max_distance parameter. Default is meters. Must be the name of a linear unit of measure from the unit_name column of the st_units_of_measure table. © 2016 IBM Corporation

Usage Run STS_GetFirstTimeByPoint () to find when an object first passed within the specified distance of the specified position during the specified time range. If you do not specify a time range, the function returns the first time that an object passed close enough to the position. If the object was too far away from the position during the time range, the STS_GetFirstTimeByPoint function returns NULL. Returns A time stamp NULL if the trajectory of the object during the time range was always farther than the maximum distance from the position. Example: Find the first time that the vehicle ever passed the position © 2016 IBM Corporation

The following query returns the first time ever that vehicle 1 passed within 100 meters of the point ( ): SELECT STS_GetFirstTimeByPoint('T_Vehicle', modid, ts_track, null, null, '4326 point( )', 100) FROM T_Vehicle WHERE modid = '1'; (expression) :37: 1 row(s) retrieved. Example: Find the first time that the vehicle passed the position in a time range © 2016 IBM Corporation

The following query returns the first time that vehicle 1 passed within 100 meters of the point ( ) between :39:00 and :30:00: SELECT STS_GetFirstTimeByPoint ('T_Vehicle', modid, ts_track, ' :39:00', ' :30:00', '4326 point( )', 100) FROM T_Vehicle WHERE modid='1'; (expression) :40: 1 row(s) retrieved. © 2016 IBM Corporation

Appendix A - STS_GetNearestObject() (1)
Find the nearest object to a point at a specific time. Syntax STS_GetNearestObject(ts_tabname LVARCHAR, ts_colname LVARCHAR, timestamp DATETIME YEAR TO FRACTION(5), geometry LVARCHAR, max_distance REAL) returns LVARCHAR ts_colname LVARCHAR, timestamp DATETIME YEAR TO FRACTION(5), geometry LVARCHAR, max_distance REAL, uom LVARCHAR) © 2016 IBM Corporation

Appendix A - TS_GetNearestObject() (2)
ts_tabname The name of the time series table. ts_colname The name of the TimeSeries column. timestamp The time point to query. geometry The geometry at the center of the region of interest. Can be an ST_Point, ST_MultiPoint, ST_LineString, ST_MultiLineString, ST_Polygon, or ST_MultiPolygon. Must use the SRID 4326. max_distance The distance from the geometry that defines the border of the region of interest. The unit of measure is specified by the uom parameter. uom (Optional) The unit of measure for the max_distance parameter. The default is meters. Must be the name of a linear unit of measure from the unit_name column of the st_units_of_measure table. © 2016 IBM Corporation

Appendix A - TS_GetNearestObject() (3)
Usage Run STS_GetNearestObject to find which object was closest to a location but within a specific distance at a specific time. If you specify that 0 meters distance from the point, STS_GetNearestObject returns the closest object regardless of the distance. Returns The object ID. Or NULL, if nothing found. Example The following statement returns the vehicle ID whose location was the closest to the point (10,10), but within 1010 meters, at :36:00: EXECUTE FUNCTION STS_GetNearestObject('T_Vehicle', 'ts_track', ' :36:00', '4326 point( )', 1010); (expression) 1 1 row(s) retrieved. Space on slide save by deleting two lines on either side of the expression return statement line. © 2016 IBM Corporation 306

Appendix A - STS_GetTrajectory() (1)
Find the exact trajectory for a time range Syntax: STS_GetTrajectory(ts TimeSeries, starttime DATETIME YEAR TO FRACTION(5), endtime DATETIME YEAR TO FRACTION(5)) returns LVARCHAR ts The time series. starttime The start of the time range. endtime The end of the time range. © 2016 IBM Corporation

Run STS_GetTrajectory to find where an object went (its path) during a time range, which is based on the data in the time series table. The location for each time point in the range is extracted from the time series table and converted into one or more linestrings. Identify which object to track in the WHERE clause of the query. Returns An LVARCHAR string that represents the trajectory of the object. The string includes the spatial reference ID and a multilinestring that consists of multiple sets of longitude and latitude values. NULL, if nothing found. Example: Get the trajectory between specific times © 2016 IBM Corporation

Example: The following query returns the trajectory of the vehicle 1 between :00:00 and :30:00: SELECT STS_GetTrajectory (ts_track, ' :00:00', ' :30:00') FROM T_Vehicle WHERE modid='1'; (expression) 4326 multilinestring(( , , , , , )) 1 row(s) retrieved. © 2016 IBM Corporation

Example: Get the trajectory from a specific time until the current time The following query returns the trajectory of the vehicle 1 between :00:00 and the current time: SELECT STS_GetTrajectory (ts_track, ' :00:00', current) FROM T_Vehicle WHERE modid='1'; (expression) 4326 multilinestring(( , , , , , ),( , , , )) 1 row(s) retrieved. © 2016 IBM Corporation

Appendix A - STS_GetCompactTrajectory() (1)
STS_GetCompactTrajectory returns the compressed trajectory of a specified object for the specified time range. Syntax STS_GetCompactTrajectory(ts_tabname LVARCHAR, obj_id LVARCHAR, ts TimeSeries, starttime DATETIME YEAR TO FRACTION(5), endtime DATETIME YEAR TO FRACTION(5)) returns LVARCHAR © 2016 IBM Corporation

ts_tabname The name of the time series table. obj_id The ID of the object. Must be a value from the primary key column of the time series table. Can be the name of the column that stores the object IDs if the WHERE clause specifies a specific object ID. ts The name of the TimeSeries column. starttime The start of the time range. endtime The end of the time range. © 2016 IBM Corporation

Run STS_GetCompactTrajectory to find where an object went during a time range, based on the compressed spatiotemporal search data. The trajectory information is retrieved from the subtack table and returned as one or more linestrings. Returns An LVARCHAR string that represents the trajectory of the object. The string includes the spatial reference ID and an ST_MultiLinestring. NULL, if nothing found. © 2016 IBM Corporation 313

Example The following query returns the trajectory of the vehicle 1 between :00:00 and :30:00: SELECT STS_GetCompactTrajectory('T_Vehicle', modid, 'ts_track', ' :00:00', ' :30:00') FROM T_Vehicle WHERE modid='1'; (expression) 4326 multilinestring(( , , , , , , )) 1 row(s) retrieved. © 2016 IBM Corporation

Appendix A - STS_GetIntersectSet() (1)
The set of objects whose trajectories intersected a region during the time range. Syntax STS_GetIntersectSet(ts_tabname LVARCHAR, ts_colname LVARCHAR, starttime DATETIME YEAR TO FRACTION(5), endtime DATETIME YEAR TO FRACTION(5), geometry LVARCHAR, max_distance REAL) returns Set(LVARCHAR) ts_colname LVARCHAR, starttime DATETIME YEAR TO FRACTION(5), endtime DATETIME YEAR TO FRACTION(5), geometry LVARCHAR, max_distance REAL, uom LVARCHAR) © 2016 IBM Corporation

Syntax (cont’d) ts_tabname The name of the time series table. ts_column The name of the TimeSeries column. starttime The start of the time range. endtime The end of the time range. geometry The geometry at the center of the region of interest. Can be an ST_Point, ST_MultiPoint, ST_LineString, ST_MultiLineString, ST_Polygon, or ST_MultiPolygon. Must use the SRID 4326. max_distance The distance from the geometry that defines the border of the region of interest. The unit of measure is specified by the uom parameter. © 2016 IBM Corporation

Syntax (cont’d) uom (Optional) The unit of measure for the max_distance parameter. The default is meters. Must be the name of a linear unit of measure from the unit_name column of the st_units_of_measure table. Usage Run STS_GetIntersectSet to find which objects intersected a region during a time range. Returns A set of object IDs. NULL, if nothing found. © 2016 IBM Corporation

Example The following statement returns the vehicles IDs that intersected the region within 1000 meters of the point (116.4, 39.91) during the time between :36:00 and :54:00: EXECUTE FUNCTION STS_GetIntersectSet ('T_Vehicle', 'ts_track', ' :36:00', ' :54:00', '4326 point( )', 1000); (expression) SET{'1','2'} 1 row(s) retrieved. The query returned the IDs 1 and 2. © 2016 IBM Corporation

Appendix A - STS_GetLocWithinSet() (1)
The set of objects that were within a region at a specific time: Syntax: STS_GetLocWithinSet(ts_tabname LVARCHAR, ts_colname LVARCHAR, timestamp DATETIME YEAR TO FRACTION(5), geometry LVARCHAR, max_distance REAL) returns Set(LVARCHAR) ts_colname LVARCHAR, timestamp DATETIME YEAR TO FRACTION(5), geometry LVARCHAR, max_distance REAL, uom LVARCHAR) © 2016 IBM Corporation

ts_tabname The name of the time series table. ts_colname The name of the TimeSeries column. timestamp The time point to query. geometry The geometry at the center of the region of interest. Can be an ST_Point, ST_MultiPoint, ST_LineString, ST_MultiLineString, ST_Polygon, or ST_MultiPolygon. Must use the SRID 4326. max_distance The distance from the geometry that defines the border of the region of interest. The unit of measure is specified by the uom parameter. uom (optional) The unit of measure for the max_distance parameter. The default is meters. Must be the name of a linear unit of measure from the unit_name column of the st_units_of_measure table. © 2016 IBM Corporation

Run STS_GetLocWithinSet () to find which objects were in a region at a specific time. Returns A set of object IDs. NULL, if nothing found. Example The following statement returns the IDs of vehicles that were within 1000 meters of the point (116.4, 39.91) at :36:00: EXECUTE FUNCTION STS_GetLocWithinSet('T_Vehicle', 'ts_track', ' :36:00', '4326 point( )', 1000); (expression) SET{'1','2'} The query returns the IDs 1 and 2. © 2016 IBM Corporation

Appendix A - STS_TrajectoryDistance() (1)
The shortest distance between a point and the trajectory of an object during a time range. Syntax STS_TrajectoryDistance(ts_tabname LVARCHAR, obj_id LVARCHAR, ts_colname LVARCHAR, starttime DATETIME YEAR TO FRACTION(5), endtime DATETIME YEAR TO FRACTION(5), geometry LVARCHAR) returns FLOAT geometry LVARCHAR, uom LVARCHAR) © 2016 IBM Corporation

ts_tabname The name of the time series table. obj_id The ID of the object. Must be a value from the primary key column of the time series table. Can be the name of the column that stores the object IDs if the WHERE clause specifies a specific object ID. ts_colname The name of the TimeSeries column. starttime The start of the time range. Can be NULL. endtime The end of the time range. © 2016 IBM Corporation

Syntax (cont’d) geometry The geometry at the center of the region of interest. Can be an ST_Point, ST_MultiPoint, ST_LineString, ST_MultiLineString, ST_Polygon, or ST_MultiPolygon. Must use the SRID 4326. uom (optional) The unit of measure for the return value. The default is meters. Must be the name of a linear unit of measure from the unit_name column of the st_units_of_measure table. Run STS_TrajectoryDistance () to find how close and object came to a specific point during a time range. © 2016 IBM Corporation

Returns A FLOAT value that represents the distance in the specified unit of measure. NULL, if nothing found. Example The following query returns the shortest distance in meters between the trajectory of vehicle 1 and the point ( ) between :35:00 and :54:00: SELECT STS_TrajectoryDistance ('T_Vehicle', modid, 'ts_track', ' :35:00', ' :54:00', '4326 point( )')::decimal(10,2) FROM T_Vehicle WHERE modid='1'; (expression) 830.36 1 row(s) retrieved. © 2016 IBM Corporation

Appendix A - STS_TrajectoryWithin() (1)
Indicates whether the trajectory of a specified object stayed within the specified region during the specified time range. Syntax STS_TrajectoryWithin(ts_tabname LVARCHAR, obj_id LVARCHAR, ts_colname LVARCHAR, starttime DATETIME YEAR TO FRACTION(5), endtime DATETIME YEAR TO FRACTION(5), geometry LVARCHAR, max_distance REAL) returns Boolean max_distance REAL, uom LVARCHAR) © 2016 IBM Corporation

ts_tabname The name of the time series table. obj_id The ID of the object. Must be a value from the primary key column of the time series table. Can be the name of the column that stores the object IDs if the WHERE clause specifies a specific object ID. ts_colname The name of the TimeSeries column. starttime The start of the time range. Can be NULL. endtime The end of the time range. Can be NULL. geometry The geometry at the center of the region of interest. Can be an ST_Point, ST_MultiPoint, ST_LineString, ST_MultiLineString, ST_Polygon, or ST_MultiPolygon. Must use the SRID 4326. © 2016 IBM Corporation

max_distance The distance from the geometry that defines the border of the region of interest. The unit of measure is specified by the uom parameter. uom (optional) The unit of measure for the max_distance parameter. The default is meters. Must be the name of a linear unit of measure from the unit_name column of the st_units_of_measure table. Usage Run STS_TrajectoryWithin to find out whether an object stayed within a region during the entire time range. STS_TrajectoryWithin returns ‘f’ if the object was in the region for only part of the time range or if the object was never in the region during the time range. © 2016 IBM Corporation

Returns t If the trajectory of the object was within the region during the entire time range. f If the trajectory of the object was within the region for only part of the time range. If the trajectory of the object was not within the region during the time range. The following query returns whether vehicle 1 stayed within 1000 meters of the point (116.4, 39.91) between :34:00 and :54:00: SELECT STS_TrajectoryWithin ('T_Vehicle', modid, 'ts_track', ' :34:00', ' :54:00', '4326 point( )', 1000) FROM T_Vehicle WHERE modid='1'; (expression) 1 row(s) retrieved. © 2016 IBM Corporation

Appendix A - STS_TrajectoryCross() (1)
Whether the trajectory crossed the boundary of the region in the time range: Syntax STS_TrajectoryCross(ts_tabname LVARCHAR, obj_id LVARCHAR, ts_colname LVARCHAR, starttime DATETIME YEAR TO FRACTION(5), endtime DATETIME YEAR TO FRACTION(5), geometry LVARCHAR, max_distance REAL) returns Boolean obj_id LVARCHAR, ts_colname LVARCHAR, starttime DATETIME YEAR TO FRACTION(5), endtime DATETIME YEAR TO FRACTION(5), geometry LVARCHAR, max_distance REAL, uom LVARCHAR) © 2016 IBM Corporation

ts_tabname The name of the time series table. obj_id The ID of the object. Must be a value from the primary key column of the time series table. Can be the name of the column that stores the object IDs if the WHERE clause specifies a specific object ID. ts_colname The name of the TimeSeries column. starttime The start of the time range. endtime The end of the time range. geometry The geometry at the center of the region of interest. Can be an ST_Point, ST_MultiPoint, ST_LineString, ST_MultiLineString, ST_Polygon, or ST_MultiPolygon. Must use the SRID 4326. © 2016 IBM Corporation

max_distance The distance from the geometry that defines the border of the region of interest. The unit of measure is specified by the uom parameter. uom (optional) The unit of measure for the max_distance parameter. The default is meters. Must be the name of a linear unit of measure from the unit_name column of the st_units_of_measure table. Run STS_TrajectoryCross () to know whether an object crossed the boundary of a specific region during a time range. STS_TrajectoryCross () Returns t if the object crossed the boundary of the region one or more times during the time range. Returns f if the object remained either outside or inside of the region for the time range (did not cross the boundary). © 2016 IBM Corporation 332

The following query returns whether vehicle 1 crossed the boundary of the region, which is specified by the point (116.4, 39.91) and the distance of 1000 meters, between :34:00 and :54:00: SELECT STS_TrajectoryCross ('T_Vehicle', modid, 'ts_track', ' :34:00', ' :54:00', '4326 point( )', 1000) FROM T_Vehicle WHERE modid = '1'; (expression) t 1 row(s) retrieved. © 2016 IBM Corporation

Appendix A - STS_TrajectoryIntersect()(1)
Indicates whether the trajectory either crossed or remained within, the boundary of the region for the time range. Syntax STS_TrajectoryIntersect(ts_tabname LVARCHAR, obj_id LVARCHAR, ts_colname LVARCHAR, starttime DATETIME YEAR TO FRACTION(5), endtime DATETIME YEAR TO FRACTION(5), geometry LVARCHAR, max_distance REAL) returns Boolean obj_id LVARCHAR, ts_colname LVARCHAR, max_distance REAL, uom LVARCHAR) © 2016 IBM Corporation

ts_tabname The name of the time series table. obj_id The ID of the object. Must be a value from the primary key column of the time series table. Can be the name of the column that stores the object IDs if the WHERE clause specifies a specific object ID. ts_colname The name of the TimeSeries column. starttime The start of the time range. endtime The end of the time range. geometry The geometry at the center of the region of interest. Can be an ST_Point, ST_MultiPoint, ST_LineString, ST_MultiLineString, ST_Polygon, or ST_MultiPolygon. Must use the SRID 4326. © 2016 IBM Corporation

max_distance The distance from the geometry that defines the border of the region of interest. The unit of measure is specified by the uom parameter. uom (optional) The unit of measure for the max_distance parameter. The default is meters. Must be the name of a linear unit of measure from the unit_name column of the st_units_of_measure table. Run STS_TrajectoryIntersect () to find out whether the specified object went through the specified region during the specified time range. Intersection means either crossed the boundary of the region or remained within the boundary of the region. © 2016 IBM Corporation

Returns t If the trajectory of the object crossed the boundary of the region during the time range. If the trajectory of the object remained within the region during the time range. f if the trajectory of the object did not intersect the region during the time range. © 2016 IBM Corporation

The following query returns whether vehicle 1 intersected the boundary of the region, which is described by the point (116.4, 39.91) and the distance of 1000 meters, between :34:00 and :54:00: SELECT STS_TrajectoryIntersect ('T_Vehicle', modid, 'ts_track', ' :34:00', ' :54:00', '4326 point( )', 1000) FROM T_Vehicle WHERE modid = '1'; (expression) t 1 row(s) retrieved. © 2016 IBM Corporation

Appendix A - STS_Release()
The STS_Release function returns the internal version number and build date for the spatiotemporal search extension. Syntax STS_Release() Returns LVARCHAR; Returns A string with the version number and build date. The following statement returns the version number and build date: EXECUTE FUNCTION STS_Release; © 2016 IBM Corporation

Appendix A - STS_Set_Trace() procedure (1)
STS_Set_Trace enables tracing and sets the tracing file. Syntax STS_Set_Trace(trace_params LVARCHAR, trace_file LVARCHAR); trace_params The tracing parameters in the following format: tracing_type tracing_level: tracing_type STSQuery: Set tracing on spatiotemporal queries. STSBuild: Set tracing on spatiotemporal indexing. tracing_level 0 = Turn off tracing. >1 = Any integer greater than 1 = Turn on tracing. trace_file The full path and name of the tracing file. © 2016 IBM Corporation

Run STS_Set_Trace with the STSQuery value to enable tracing if you want to view the entry points of spatiotemporal query functions. Run STS_Set_Trace with the STSBuild value to enable tracing if you want to view the entry points of spatiotemporal indexing functions. You must specify the full path and name of the tracing file. © 2016 IBM Corporation 341

Set query tracing The following statement starts tracing on spatiotemporal queries and sets the tracing file name and path: EXECUTE PROCEDURE STS_Set_Trace('STSQuery 2', '/tms/sts_query.log'); Stop query tracing The following statement stops tracing on spatiotemporal queries: EXECUTE PROCEDURE STS_Set_Trace('STSQuery 0', '/tms/sts_query.log'); © 2016 IBM Corporation

Appendix B - STS_DefaultParameters Table
Contains the default parameters document for the database and the table is empty until you run the STS_SetDefaultParameters function. If you omit the parameters document from the STS_SubtrackCreate function, the values in this table are used. The STS_DefaultParametersTable table contains a parameters column, which is of type BSON, and only one row, which contains the default parameters document. You can update the default parameters document with the STS_SetDefaultParameters function. The existing default parameters document is replaced. © 2016 IBM Corporation

Appendix B - STS_InstanceTable
The table contains the association between a time series instance and a subtrack definition. Every time series that has subtrack records in a subtrack table has a row in the STS_InstanceTable table. The following table lists the columns of the STS_InstanceTable table: The time series instance ID is listed in the TSInstanceTable table. Column Data Type Description instance_id BIGINT Time Series instance ID. The primary key subtrack_id INTEGER Unique ID of the subtrack table © 2016 IBM Corporation

Appendix B - STS_SubtrackTable
Column name Data type Description subtrack_id SERIAL The unique ID of the subtrack table. subtrack_name VARCHAR(128) The name of the subtrack table. The primary key. base_table_name The name of the time series table. ts_column_name The time series column name in the time series table. flags INTEGER Specifies whether a Scheduler task indexes new data: 1 = A Scheduler task is running. 2 = No Scheduler task. parameters BSON A BSON document that contains parameters to build the subtrack. ts_data_first_timestamp DATETIME YEAR TO SECOND First time stamp in the time series to index with the Scheduler task. ts_data_lag_to_current INTERVAL DAY TO SECOND Time interval before current time to avoid indexing with the Scheduler task. task_nschsessions Number of Scheduler sessions to start to update the index in parallel. task_frequency How frequently to index new data with the Scheduler task. task_start_time DATETIME HOUR TO SECOND First time to start the Schedule task. task_data_interval_to_process Time interval in the time series to process each time that the Scheduler task is run. © 2016 IBM Corporation

Appendix B - STS_SubtrackTable
The STS_SubtrackTable table contains the subtrack definitions. When you run the STS_SubtrackCreate function, a row is added to the STS_SubtrackTable table. © 2016 IBM Corporation

Appendix B - Subtrack table
Contains spatiotemporal data for the associated time series column. You specify the name of the subtrack table when you run the STS_SubtrackCreate function. Column name Data type Description instance_id BIGINT The time series instance ID. begin_time DATETIME YEAR TO FRACTION(5) The start time of the entry. end_time The end time of the entry. state SMALLINT The type of entry: 0 = Moving. The geometry column contains a trajectory. 1 = Stationary. The geometry column contains a location. 2 = No signal. The object had no signal for the time period between the start time and the end time, and the object is in the same location. 3 = Interrupted signal. The object had no signal for the time period between the start time and the end time, and the object is in a different location. geometry ST_Geometry Depends on the value of the state column: 0 = An ST_LineString or ST_MultiLineString that represents the trajectory of the object. 1 = An ST_Point that represents the location of the object. 2 or 3 = NULL © 2016 IBM Corporation

Informix xC5, xC6 & xC7 – New Features

Similar presentations

Presentation on theme: "Informix xC5, xC6 & xC7 – New Features"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Informix xC5, xC6 & xC7 – New Features

Similar presentations

Presentation on theme: "Informix xC5, xC6 & xC7 – New Features"— Presentation transcript:

Similar presentations

About project

Feedback