Accessing VectorH
Start or Shut Down the Vector Instance
You start or shut down VectorH on the master node using the ingstart or ingstop commands. VectorH on the slave nodes is started and stopped automatically.
Note: You must shut down VectorH before shutting down the HDFS or the Hadoop cluster.
To start the instance
1. Log on to your system through the system administrator account for the instance and source the environment script.
2. Enter the following command:
ingstart
The ingstart command checks whether you have sufficient operating system resources to run the product components. If so, ingstart starts all servers that are part of your instance.
To stop the instance
Enter the following command:
ingstop
The instance is stopped.
Start Vector as a Service
During installation, a script is generated that automatically starts Vector as a service unless you used the Install VectorH Using the Ingbuild Distribution (Express Installation).
Note: To generate and install the script, use the mkrc command.
The generated script to start Vector for Linux as a service is installed under /etc/init.d. The service is named actian-vectorXX, where XX is the instance ID, the value for II_INSTALLATION, specified during installation (default is VW for Vector and VH for VectorH).
To start the Vector instance as a service
Run the following as root:
/sbin/service actian-vectorXX start
where XX is the instance ID.
To stop and restart the service
Use the following commands:
/sbin/service actian-vectorXX stop
/sbin/service actian-vectorXX restart
where XX is the instance ID.
Network Connections
Ingres Net must be installed to allow a Vector client to access databases on another instance.
Any installation configuration in which the client and server processes do not reside in the same instance or on the same machine must use Ingres Net. With Ingres Net on each Vector instance in your network, you can access databases on your local node and on remote nodes.
Ingres Net is included in the Client component when installing Vector. If the Client component is installed, then Ingres Net is automatically started when you start your Vector instance.
The following components are automatically installed with Ingres Net:
• Data Access Server
Provides network access to the DBMS Server for JDBC drivers and .NET Data Providers.
• JDBC Driver
User Authentication
Each Vector user must be defined in the master database. For example, the installation owner creates a user in iidbdb:
CREATE USER fred WITH PASSWORD = 'secret';
Vector can use either of the following methods to authenticate users:
• Through the operating system (OS) account and password together with the corresponding user object definition in the master database.
• By passing the user name and password directly to the DBMS Server for DBMS authentication against the list of Vector users and their passwords. If dbms_authentication is enabled for the server (which it is by default for new installations), the user does not have to be defined as an operating system user.
For details, see DBMS Authentication in the Security Guide.
Ingres Net can be configured to allow users access to remote nodes directly (through an installation password) or by providing a user name and password. The user name and password can be authenticated by the DBMS (if the server has DBMS authentication enabled), or against a local OS user account. The password is encrypted when sent across the network.
User Password
A password can be specified as part of the user definition. The usage of the user password depends on whether DBMS authentication is enabled.
If DBMS authentication is enabled, the user name and password supplied by the connection attempt must match the user name and password defined in the user definition. If no password is supplied by the connecting application, the connection attempt fails.
If DBMS authentication is not enabled, the DBMS password operates as a second level of password after the initial connection is established (using the configured GCF security mechanism, such as authentication against an OS user and password). In this case, the application sends the DBMS password in the clear, after the connection is established. If the application does not provide a DBMS password, the DBMS server asks the client to prompt for one; if prompting is impossible, the connection attempt fails.
Note: If a user with the Security privilege starts a session using the –u flag to impersonate another user, the real user’s password—not the impersonator’s—is required.
A user with the CHANGE_PASSWORD privilege is permitted to change their own password; to do so, however, they must supply their old password. A user with the maintain_users privilege can change the password of another user in addition to changing the method of password validation or removing the password.
Connecting to a Database
The syntax for connecting to a database depends on whether the target database server is local or remote.
Connecting to a Local Server
The following connection examples assume that the configuration parameter dbms_authentication=on for the server.
A user logged in locally (on the server machine) can connect as follows:
sql dbname
This assumes that the user is defined WITH DBMS_AUTHENTICATION='OPTIONAL'. Even if the user has a DBMS password, neither password prompt nor DBMS password validation occurs. If the user is defined WITH DBMS_AUTHENTICATION='REQUIRED', the connection attempt fails because no user name or password was supplied.
A user can also connect, either as himself or as another Vector user, using DBMS authentication. He can use the +user option or the local-vnode syntax:
sql +user dbname
The user is prompted for the password and connects as the logged-in OS user.
sql +user=fred dbname
The user is prompted for the password and connects as user fred. Fred need not be an OS user.
sql '@[fred,secret]::dbname'
The user enters the password on the command line. Fred need not be an OS user.
Note: If dbms_authentication is not enabled on the server, the last two examples will work, except that fred would have to be an OS user, and the password would have to be fred's OS password. If fred has a DBMS password defined, with dbms_authentication off, the server requests a password prompt for the DBMS password (thus, the +user=fred example might get two password prompts).
The +user option does not conflict with the effective user option (‑u). For example, if user fred has DB_ADMIN privileges for the database, he can connect and authenticate as himself, but then run the session with a different effective user:
sql +user=fred -u ralph dbname
The user (fred) is prompted for his password, and fred and password are authenticated by the DBMS. After the session is established, the effective user (ralph) is set.
Connecting to a Remote Server
If connecting to a remote server where dbms_authentication=on, a user can use either a vnode or dynamic vnode syntax:
sql vnode::dbname
The user name and password in the vnode definition are used.
sql '@host,tcp_ip,VW[fred,secret]::dbname'
The user name and password are entered on the command line.
sql +user=fred @host,tcp_ip,VW::dbname
Prompts for password. Because the +user flag is used, the [username, password] syntax cannot be specified on the dynamic vnode.
Connections established through API-based applications such as ODBC, JDBC, and .NET Data Provider directly specify a user name and password. A DBMS password sent by such an application to a dbms_authentication enabled server is meaningless and ignored.
Connecting to a Non-UTF8 Server that Does Not Support Transliteration
When establishing a connection from a Vector instance to a non-UTF8 server that does not support transliteration (such as an Ingres instance that uses a native character set), you must declare the character set used for the connection.
The character set specified must match or be compatible with the character set of the target server instance. So if you are connecting from a Vector client on Linux to an Ingres instance on Windows, you can specify WIN1252, which matches the character set on the Ingres for Windows installation.
The character set can be declared in a vnode or in the connection string by using the connection attribute “character_set” (or the shorter “charset”), using the following format:
@host,port;character_set=charset[user,pwd]::dbname
where port is the listen address of the instance on the remote node.
For example, the following dynamic vnode specification starts the terminal monitor and uses the WIN1252 character set to connect to the inventorydb database:
sql @hosta,VW;character_set=win1252[Susan,mypassword]::inventorydb