Management Domains

A Management Domain consists of the IMA objects visible to a Management Application. This domain is session-specific and by default is the MIB server to which the session is connected. This is the only server of the current session that is managed. It can be a local server or a remote server connected to across Ingres Net.

There are three objects (classid) that can be used to extend or reduce the size of the managed domain:

• 'exp.gwf.gwm.session.control.add_vnode'
• 'exp.gwf.gwm.session.control.del_vnode'
• 'exp.gwf.gwm.session.control.reset_domain'

To add a vnode to the domain it is necessary to update the classid in ima_mib_objects (or the table that has been defined to be the 'objects' table).

Extending the Domain in the Local Instance

The following SQL update extends the domain from the MIB server to all servers in the local instance of Ingres. This makes visible, for example, other DBMS servers, logging and locking objects, RCP and ACP:

UPDATE ima_mib_objects

SET    value        = DBMSINFO('IMA_VNODE')

WHERE  classid      = 'exp.gwf.gwm.session.control.add_vnode'

AND    instance     = '0'

AND    server       = DBMSINFO('IMA_SERVER');

It is not necessary to use DBMSINFO('IMA_SERVER') to define the name of the MIB server to which the session is connected; DBMSINFO('IMA_SERVER') could be replaced by a program variable or a hard coded value, but DBMSINFO('IMA_SERVER') is used for ease and to make the SQL generic across operating systems.

As the above SQL is extending the local MIB server domain, it is necessary to set the value of the "value" column to the local VNODE, which can be retrieved through the use of a program variable with the value in, a hard coded value, or through DBMSINFO('IMA_VNODE').

Note: Updating the "value" column will not actually change what is in the column; it is an instruction to the MIB server to expose the other servers in that VNODE.

Below is an example of the count of the number of classid and instances done before and after the local domain is extended:

The actual values will change depending on the number of servers running, the number of sessions, and so on.

Extending the Domain to a Remote Instance

To extend the domain to remote instance of Ingres, the instance needs to be reachable through Ingres Net. This can be done using netutil or VDBA. The login to the remote instance can either be done using an installation password or to a suitably privileged Ingres user, for example, "root".

To extend the domain to a remote VNODE called "GRFR6," the following SQL update must be done:

UPDATE ima_mib_objects

SET    value        = 'GRFR6'

WHERE  classid      = 'exp.gwf.gwm.session.control.add_vnode'

AND    instance     = '0'

AND    server       = DBMSINFO('IMA_SERVER');

The value 'GRFR' can be put into a program variable. Note that server is still the local MIB server as it is its domain that is being extended.

Removing a Remote Instance Domain

To remove the 'GRFR6' VNODE from the MIB server domain, it is necessary to update the classid 'exp.gwf.gwm.session.control.del_vnode'. Doing so does not actually change the value in the ima_mib_objects table, but is an instruction to remove the objects from the visible domain.

The following SQL shows the update:

UPDATE ima_mib_objects

SET    value        = 'GRFR6'

WHERE  classid      = 'exp.gwf.gwm.session.control.del_vnode'

AND    instance     = '0'

AND    server       = DBMSINFO('IMA_SERVER');

Restoring the Domain

To return the domain for the MIB server to the original default, it is necessary to update the classid 'exp.gwf.gwm.session.control.reset_domain'. Doing so does not actually change the value in the ima_mib_objects table, but is an instruction to remove the objects from the visible domain.

The following SQL shows the update:

UPDATE ima_mib_objects

SET    value        = DBMSINFO('IMA_VNODE')

WHERE  classid      = 'exp.gwf.gwm.session.control.reset_domain'

AND    instance     = '0'

AND    server       = DBMSINFO('IMA_SERVER');

To simplify this process further, the IMADB database contains database procedures:

• ima_set_server_domain

  This procedure takes no parameters. It updates the "exp.gwf.gwm.session.control.reset_domain' object.

• ima_set_vnode_domain

  This procedure takes a parameter of a VNODE. It updates the 'exp.gwf.gwm.session.control.add_vnode' object.

Control Objects

In the same way that there are control objects that can be updated to add or delete a VNODE from a MIB server domain, there are other control objects that can be updated, using the SQL statement UPDATE.

The following is a sample of some of the control objects and their effect:

To simplify using some of these control objects, the IMADB database contains the following database procedures:

• ima_close_server
• ima_drop_all_sessions
• ima_drop_sessions
• ima_open_server
• ima_remove_session
• ima_shut_server
• ima_start_sampler
• ima_stop_sampler

Restrictions in IMA Use

Following is a summary of current restrictions within IMA:

• Support for data types is limited in table registrations.
  • Only INTEGER, VARCHAR, and CHAR data types can be specified as data types in the REGISTER TABLE statement.
  • All columns must be NOT NULL NOT DEFAULT.
• The IMA supports full SQL but with the following restrictions:
  • There is no locking or lock ownership of IMA underlying objects.
  • There are no transactions for updates for IMA objects.
  • Updates take immediate action and cannot be rolled back.
  • All reads are "dirty." This means that querying the same object may return different values because the data underlying the record could have changed.
  • Rule triggering is unreliable. Rules are not triggered when the value of an object changes in a way unknown through SQL. This occurs to IMA related data as the installation operates. Thus, while updates that are performed through SQL can trigger rules, rule integrity cannot be guaranteed for IMA data.
• The group of defined objects supplied with the IMADB database is subject to change in subsequent releases.
• A cluster installation is visible to IMA as the installations on each node within a domain.