OpenText Analytics Database 26.2.x – Advanced menu options

Admin: Rolling back the database to the last good epoch

Mon, 01 Jan 0001 00:00:00 +0000

OpenText™ Analytics Database provides the ability to roll the entire database back to a specific epoch primarily to assist in the correction of human errors during data loads or other accidental corruptions. For example, suppose that you have been performing a bulk load and the cluster went down during a particular COPY command. You might want to discard all epochs back to the point at which the previous COPY command committed and run the one that did not finish again. You can determine that point by examining the log files (see Monitoring the Log Files).

On the Advanced Menu, select Roll Back Database to Last Good Epoch.
Select the database to roll back. The database must be stopped.
Accept the suggested restart epoch or specify a different one.
Confirm that you want to discard the changes after the specified epoch.

The database restarts successfully.

Important

The default value of HistoryRetentionTime is 0, which means that the database only keeps historical data when nodes are down. This settings prevents the use of the Administration tools 'Roll Back Database to Last Good Epoch' option because the AHM remains close to the current epoch. The database cannot roll back to an epoch that precedes the AHM.

If you rely on the Roll Back option to remove recently loaded data, consider setting a day-wide window for removing loaded data. For example:

=> ALTER DATABASE DEFAULT SET HistoryRetentionTime = 86400;

Admin: Stopping the database on host

Mon, 01 Jan 0001 00:00:00 +0000

This command attempts to gracefully shut down the database process on a single node.

Caution

Do not use this command to shut down the entire cluster. Instead, stop the database to perform a clean shutdown that minimizes data loss.

On the Advanced Menu, select Stop Vertica on Host and click OK.
Select the hosts to stop.
Confirm that you want to stop the hosts.

If the command succeeds View Database Cluster State shows that the selected hosts are DOWN.

If the command fails to stop any selected nodes, proceed to killing the database process on host.

Admin: Killing the database process on host

Mon, 01 Jan 0001 00:00:00 +0000

This command sends a kill signal to the database process on a node.

Caution

Use this command only after you tried to stop the database and stop database on a node and both were unsuccessful.

On the Advanced menu, select Kill Vertica Process on Host and click OK.
Select the hosts on which to kills the database process.
Confirm that you want to stop the processes.
If the command succeeds, View Database Cluster State shows that the selected hosts are DOWN.

Admin: Upgrading a database license key

Mon, 01 Jan 0001 00:00:00 +0000

The following steps are for licensed users. Completing the steps copies a license key file into the database. See Managing licenses for more information.

On the Advanced menu select Upgrade License Key . Click OK.
Select the database for which to upgrade the license key.
Enter the absolute pathname of your downloaded license key file (for example, /tmp/vlicense.dat). Click OK.
Click OK when you see a message indicating that the upgrade succeeded.

Note

If you are using a Trial license, follow the instructions in License changes to upgrade to commercial license.

Admin: Managing clusters

Mon, 01 Jan 0001 00:00:00 +0000

Cluster Management lets you add, replace, or remove hosts from a database cluster. These processes are usually part of a larger process of adding, removing, or replacing a database node.

Note

View the database state to verify that it is running. See View Database Cluster State. If the database isn't running, restart it. See Starting the database.

Using cluster management

To use Cluster Management:

From the Main Menu, select Advanced Menu, and then click OK.
In the Advanced Menu, select Cluster Management, and then click OK.
Select one of the following, and then click OK.
- Add Hosts to Database: See Adding Hosts to a Database.
- Re-balance Data: See Rebalancing Data.
- Replace Host: See Replacing Hosts.
- Remove Host from Database: See Removing Hosts from a Database.

Admin: Getting help on administration tools

Mon, 01 Jan 0001 00:00:00 +0000

The Help Using the Administration Tools command displays a help screen about using the Administration Tools.

Most of the online help in the Administration Tools is context-sensitive. For example, if you up the use up/down arrows to select a command, press tab to move to the Help button, and press return, you get help on the selected command.

Admin: Administration tools metadata

Mon, 01 Jan 0001 00:00:00 +0000

The Administration Tools configuration data (metadata) contains information that databases need to start, such as the hostname/IP address of each participating host in the database cluster.

To facilitate hostname resolution within the Administration Tools, all hostnames you provide through the Administration Tools use IP addresses at the command line and inside the installation utility as follows:

During installation

The installation script immediately converts all hostnames you provide through command line options --hosts, -add-hosts or --remove-hosts to their IP address equivalent.
- If you provide a hostname during installation that resolves to multiple IP addresses (such as in multi-homed systems), the installer prompts you to choose one IP address.
- The database retains the name you give for messages and prompts only; internally it stores these hostnames as IP addresses.
Within the Administration Tools

All hosts are in IP form to allow for direct comparisons (for example db = database = database.example.com).
At the command line

The database converts any hostname value to an IP address that it uses to look up the host in the configuration metadata. If a host has multiple IP addresses that are resolved, the database tests each IP address to see if it resides in the metadata, choosing the first match. No match indicates that the host is not part of the database cluster.

Metadata is more portable because the database does not require the names of the hosts in the cluster to be exactly the same when you install or upgrade your database.