|
|
|
The GUI-based tools Network Utility (ingnet) and Visual DBA can both be used to define vnodes containing the connection and authorization data used by the Communications Server to access remote instances.
Because Network Utility is a tool dedicated to defining and managing vnodes, it is preferred over netutil or Visual DBA for performing these tasks in Ingres.
System administrators (or any user with the appropriate Ingres privileges) can use these visual tools to perform the following tasks:
End users can use these visual tools to:
In Network Utility and Visual DBA, vnodes are defined using vnode objects. A vnode object specifies a virtual node name, and login and connection information.
Using the Nodes branch in the Virtual Nodes toolbar/window, you can create and alter vnodes, view vnode objects, and drop vnode objects.
Detailed steps for performing these procedures can be found in the Procedures section of online help for Network Utility and Visual DBA.
|
|
|
The Virtual Nodes toolbar in both Network Utility and Visual DBA provides the same functionality. Use the toolbar to create, alter, drop, and disconnect vnodes. The toolbar also provides features that allow you to connect to database servers and open various types of database administration utility windows.
For example, connect to the Database Object Manager and open a DOM Scratchpad. The toolbar also allows you to use an SQL Scratchpad, monitor your system performance, and display a list of Dbevents.
|
|
|
Virtual nodes are classified as simple or advanced. A simple vnode is one in which there is only one set of login and connection parameters associated with it. An advanced vnode is one in which there is more than one connection data definition and/or up to two login data definitions. For additional information, see Advanced Vnode Parameters.
|
|
|
Maintain up to two login data definitions for each vnode. If the first definition has been defined as private, the other login must be global (and vice versa). A global entry is available to all users on the local instance. A private entry is available only to the user who creates it.
If one of the login data definitions is private and the other is global, the vnode is considered to be an advanced vnode. A vnode is also considered to be an advanced vnode if it has more than one connection data definition and/or has one or more vnode attribute definitions.
Use the Advanced Node Parameters branch in Network Utility and Visual DBA to:
For additional information on performing these tasks, see the following sections.
|
|
|
If a remote instance has more than one Communications Server or can be accessed by more than one network protocol, its information can be added in the vnode definition. This allows you to distribute the load of communications processing and increase fault tolerance.
Note: When more than one Communications Server listen address is defined for a given vnode, each server is tried in random order until an available one is found. Similarly, when a connection fails over one network protocol, an attempt to make a connection with any other protocol that has been defined is tried automatically.
End users can create private connection data for an existing vnode by adding an entry to the Connection data table. For the user who creates it, a private connection data entry overrides a global connection data entry defined for the same vnode. In other words, Ingres Net uses the private connection data entry whenever the user who created the entry uses the vnode.
Note: Have the following information on hand before beginning the procedures mentioned below: the network address of the node on which the remote instance resides, the listen address of the remote instance's Communications Server, and the keyword for the network protocol that is used to make the connection.
The detailed steps for performing these procedures can be found in the Procedures section of online help for Network Utility and Visual DBA. See the following topics:
|
|
|
End users can create (as well as alter and drop) a private remote user authorization for an existing vnode. For the user who sets it up, a private authorization overrides a global authorization defined to the same vnode. In other words, Ingres Net uses the private authorization whenever the user who created it uses the vnode.
Know the following information before beginning these procedures:
Detailed steps for performing these procedures can be found in the Procedures section of online help for Network Utility and Visual DBA. See the following topics:
|
|
|
In addition to login and connection data, you can use Network Utility or Visual DBA to configure the following vnode attributes:
For a description of each attribute and its associated values, and for detailed steps for adding, altering and dropping these attributes, see the following topics in the Procedures section of online help for Network Utility and Visual DBA:
|
|
|
As previously explained, users can access a remote Ingres instance using a login account set up on the remote instance's host machine, or through an Installation Password, which allows users direct access to the instance. The Installation Password is configured for the local instance containing the databases that remote users want to access.
Detailed steps for performing this procedure can be found in the Procedures section of online help for Network Utility and Visual DBA. See the following online topic:
|
|
|
Changing installation passwords requires special care. Because of caching of information on the client and server, installation passwords must be changed at least 30 minutes after the last use of Ingres Net. Failure to do this can cause connections to fail with "E_GC0141_GCN_INPW_INVALID."
|
|
|
In addition to connection data entries and user authorization tasks, you can use Network Utility and Visual DBA to perform the following vnode-related tasks.
|
|
|
Refreshing is used to update loaded vnode data. You can selectively choose to refresh particular vnodes by either selecting the Force Refresh button on the toolbar or choosing Node, Force Refresh. You can configure your background refresh settings by choosing File, Preferences.
|
|
|
Network Utility and Visual DBA provide a way to test if a connection to a specific node can be established. From the Virtual Nodes toolbar, choose Node, Test Node to initiate a connection test. If the connection fails, an error message is returned.
|
|
|
Closing a window does not end communications with the servers on that window. Network Utility and Visual DBA continue to request data refreshes from the vnode until you disconnect from it.
Detailed steps for performing this procedure can be found in the Procedures section of online help for Network Utility and Visual DBA. See the following topic:
|
|
|
By choosing a virtual node, you can both establish a physical connection between the database server and your client workstation, and also open one of the four types of Visual DBA database administration windows.
The detailed steps for performing these procedures can be found in the Procedures section of online help for Network Utility and Visual DBA. See the following topics:
|
|
|
Servers represent server classes associated with a particular vnode. In Network Utility and Visual DBA, you can view a list of the servers that exist for a given vnode using the Servers branch in the Virtual Nodes toolbar/window.
From this branch, you can:
The detailed steps for performing these procedures can be found in the Procedures section of online help for Network Utility and Visual DBA. See the following topics: