An Octopus Class of Service is made up of one or more OctoEng�s having the same parameter settings in the SAND CDBMS configuration file (nucleus.ini). At least one Class must be defined for the Octopus system. When a single class is defined, Octopus simply distributes the execution of multiple users� queries across a set of OctoEng�s. When multiple Classes are specified for Octopus, however, each Class can be set to offer a different level of processing services devoted to a specific kind of query. Queries that require a certain level of computing resources can then be automatically sent to a specific set of OctoEng�s. This feature allows database administrators to control workflow within the system, and is particularly useful in preventing "bottleneck" situations where long-running queries tie up server resources.The configuration parameters shared by the OctoEng�s in a given Class include the following:
RescheduleTimeout (Time limit)When multiple Classes of service are configured, Octopus brings them into play according to a user-specified hierarchy. That is, if the processing of a particular query exceeds the time limit set for the current Class, the query is "promoted" and sent to an OctoEng in a Class that has been configured to provide greater processing power. This hierarchy of Classes is set with the CLASSES parameter in the appropriate OCTOPUS section of the SAND CDBMS configuration file (nucleus.ini), as in the following example:
The RescheduleTimeout parameter specifies the maximum time in seconds allowed for query execution (a setting of 0 indicates that no time limit is applied). When elapsed time reaches the specified limit, the query is terminated, and Octopus reschedules the query for execution by an OctoEng in the next specified Class (as explained in the next section, The Hierarchy of Classes).Cache (Virtual Memory)
The Cache parameter specifies the maximum amount of virtual memory (in megabytes) to be allocated to each OctoEng for database operations.MaxDeltaFileSize or MaxDeltaFileRatio (Maximum Size of the Virtual Mode Delta File)
The MaxDeltaFileSize and MaxDeltaFileRatio parameters specify the maximum size of the Delta File to which changes to the virtual database instance are written. Each OctoEng operating under Octopus has its own Delta File. MaxDeltaFileSize specifies the maximum size of this file in megabytes (default=2048, or 2 GB); MaxDeltaFileRatio expresses the maximum as a percentage of database size. A MaxDeltaFileSize value of 0 indicates no limit; when the value of MaxDeltaFileRatio is set to 0 (the default), the MaxDeltaFileSize value is used.CLASSES= LIGHT,HEAVY,UPDATEThe CLASSES parameter lists the Classes in order, from the lowest to the highest level of processing services offered. When Octopus is configured to operate in Public Update mode, the last entry in the CLASSES list (called UPDATE in the example above) is automatically defined as the Updatable Class, which is dedicated to handling commands that change the database.
Figure 2: Octopus Classes of Service
When queries are executed within a Class configured to provide unlimited processing time (RescheduleTimeout=0), processing continues until results are returned to the client. When queries are executed within Classes that do have a time limit, and the specified interval is exceeded, processing is aborted and the query is promoted to the next Class in the CLASSES list. For example, the LIGHT Class in the example pictured above has a time limit of 15 seconds; if query results are not returned to the user within that interval, command execution is canceled on the LIGHT OctoEng, and the query is redirected to an OctoEng in the HEAVY Class.
To optimize resource utilization, Octopus initially tries to send queries to an OctoEng in the last (or "heaviest") non-updatable Class in the list, in order to make use of the higher level of services provided. If all OctoEng�s in this Class are busy, Octopus checks the Class immediately preceding it in the list; if this Class is also busy, it goes to the next heaviest Class, and so on up the list until a free OctoEng is found. If none of the heavier Classes are available, the query is sent to the first Class in the CLASSES list not reserved as a Login Class, and processing proceeds according to the scheme described in the previous section.
Thus, referring again to the example given above, when Octopus receives a query from a client session, it initially directs it to the second Class (HEAVY). If all OctoEng�s in this Class are busy, the query is sent to the first Class specified in the list (LIGHT); then, if query processing time exceeds the limit set for this Class, the query is assigned or queued for execution (depending on the ShareServer setting) by an OctoEng in the HEAVY Class. The last Class (UPDATE) is reserved for the execution of SQL commands and data loads that make changes to the database.
Any names can be specified for Octopus Classes. When configuring multiple instances of the Octopus utility on a single computer, remember that using the same Class names for the different instances will result in the Class definitions being shared. To avoid this, use specific Class names for each instance.
When set to operate in the Public Update execution mode (explained in the next section), Octopus will intercept any SQL command that changes the database � such as CREATE..., DROP..., ALTER..., INSERT, UPDATE, or DELETE � and send it directly to the single OctoEng in a Class that is specially configured to handle updates. Once this command executes successfully, all subsequent queries within that transaction � that is, up to the successful execution of a COMMIT [WORK] or ROLLBACK [WORK] command � are automatically sent to the same OctoEng. Then, after the COMMIT [WORK] executes successfully, Octopus automatically refreshes the database version used by all active OctoEng�s in the Octopus system, without requiring clients to disconnect. With each successful commit, the Octopus database version number (as reported by the Octops program) increments by 0.1.
It is possible to use the SAND CDBMS Data Loader utility (ndlm) to update the database via Octopus. For more information, consult the Octopus Operations section.
In the configuration settings contained in the nucleus.ini file, the Updatable Class is defined by its position as the last entry in the list of values for the Classes parameter in the Octopus section of the nucleus.ini file. Since this Class is intended to handle changes to the database, its Cache parameter should be set to a higher value than for the other Classes, and its RescheduleTimeout parameter should be set to 0 (unlimited).
By default, an Octopus update is a virtual update that does not affect the real physical data store. Changes are not retained when Octopus is shut down. Alterations or updates to the Octopus database (performed via SQL DML statements or using the SAND CDBMS data loader utility) can be made permanent by executing the SET UPDATE KEEP CHANGE command. After this command is executed, the view of the database seen by Octopus client sessions is automatically refreshed. With each successful SET UPDATE KEEP CHANGE command (or database update performed outside the Octopus system), a new database Snapshot is created, and the Octopus database version number (as reported by the Octops program) increments by 1, to n.0.
Octopus can be instructed to reserve a special class exclusively for processing client database login requests. This feature guarantees that users will be able to log in to the database even when the system is very busy. To enable a Login class, include the LoginClass=TRUE parameter in the Octopus section of the nucleus.ini file: this reserves the first entry in the Classes list for client logins. This Class should be configured to use minimal processing resources (that is, it should comprise a single OctoEng with a small Cache size).