Qubik Lava Installation and Administration Guide Installation and Administration... · • Startup...

Qubik LavaInstallation

andAdministration

Guide

i

Table of Contents

IntroductionManual Scope and Target AudienceUsing This ReferenceSystem RequirementsReference Manual Structure

Installing the Lava Database

Mounting the Server

Starting a Lava Client

Administering a Lava Database

Importing Data

Principles of Operation

Installing the Lava DatabaseInstalling the Lava Server software suite

Executable Folder

Primary Database Folder

Temporary Client Folder

Server Address

Component Selection

Finalizing the Installation

Setting up a Lava DatabaseCreating the Primary Lava Database

Starting the Lava Query Interface

Creating a Lava Database

Possible Creation Problems

No Datapath specification

Existing Lava Database

Unspecified Creation Failure

Creating a Lava Database on a Windows NT 4 platformCreating an NT 4 database across the local network

Creating an NT 4 database on a recent Windows release

Successful Database Creation

Mounting the Lava ServerRunning the Lava Server as an ExecutableInstalling the Lava Server as a standalone serviceStarting a Standalone ServerLava Monitor installation

Lava Monitor options

Installing the Monitor service

Monitored Lava Server operationStarting a Monitored Lava Server

Standby Lava Server options

ii

Lava Server ComponentsLava Control PanelLava MonitorLava Primary Server

Starting a Lava ClientThe Lava Query Interface as a ClientConnecting to the Lava ServerIssuing a SQL QueryDisconnecting and Dismounting a Client

Administering a Lava DatabaseGeneral AdministrationBackup Procedures

Performing a Schema Backup

Restore ProceduresShutting down the Server

Using Exclusive Mount

Performing a Restore

Re-mounting the Server

Importing Data

Principles of OperationClient-ServerDistributed ClientServer Monitor ServicePrimary Server ExecutablePrimary Server ServiceStandby Server Service

iii

List of IllustrationsLava (3)

Executable folder selection (3)

Primary Database Location (4)

Lava Query Interface (6)

Creating a Database (6)

Lava Query Datapath parameter (8)

Installing the Primary Server as a Service (13)

Starting a Standalone Server (13)

Windows Security Alert (14)

Windows Security Alert (16)

Manual Scope and Target Audience

Introduction


This reference manual covers the installation and administration of a Lava Database. This includes the creation

of new databases, setting up the Lava Server, and performing backup and restore operations.

This manual is targeted at administrators and database users who wish to :

• Install a Lava Database server

• Configure the Lava Server with respect to services and monitor processes

• Perform routine queries on the server to determine operating parameters

• Monitor and control user sessions

• Perform backup and restore operations as required

Topics covered include :

• Installation

• Service configuration

• Basic use of the administration interfaces

• Startup and shutdown procedures

• Backup and restore procedures

Using This Reference

This PDF document is extensively hyperlinked. In order to derive the best usage from this document, note that

the Acrobat PDF reader has a “back” button (just like a browser) located in the toolbar, which looks like this :

After following a hyperlink (any blue underlined text) by left-clicking on the hyperlink with your mouse,

clicking the “back” button will return you to the hyperlink just accessed. The “back” button will work through

multiple levels of links.

The “back” option can also be found in the mouse right-click pop-up menu, named “Go to Previous View”.

Note that as of Acrobat 6, the “back” option is no longer presented in the pop-up menu, and the toolbar looks

slightly different :

Also, the toolbar is not displayed by default, and must be activated in the Toolbar options as follows :


There is a keyboard shortcut for the Previous View function, which is Alt+Left Arrow

System Requirements

The basic requirement for the Lava SQL Server is a minimum of Windows NT 4 with Service Pack 5 installed.

The server will install and run on the following operating systems :

Windows NT 4 (with at least Service Pack 5), 2000 or XP, or Windows Server 2000 or 2003.

The client applications included in the server installation (Lava Query and Lava Mimic) will only run on

Windows releases from Windows 2000 onward.

The clients are tested on :

Windows 2000 or XP, Windows Server 2000 or 2003.

Reference Manual Structure

The manual is divided into a number of sections, each of which addresses a specific topic.


Describes the procedure for installing the Lava Server software suite. Contains important information on the

meaning and interpretation of selections to be made during the installation process.

Mounting the Server

Details on the process of setting up and mounting a Lava Server. Includes information on how to create an

initial Lava Database, and describes available options for running the Lava Server in various modes.

Starting a Lava Client

Describes the connection process (from the user perspective) for connecting to a Lava Server from a client

application, using Lava Query as the example client.


This section describes regular administration required by a Lava Database. The most important of these is that

of regular data backup.

Importing Data


Describes methods for importing data into a Lava Database from an ODBC data source


This section should be read by any prospective power user of a Lava Database. It introduces major features,

requirements and constraints of the Lava Database, and explains important concepts which distinguish the Lava

Database from other SQL databases. All users of Lava Databases who intend to interact with the database

through any of the interface mechanisms should at least read the Key Concepts subsection.



Installing a new Lava Database comprises three major steps.

The first is to install the server software suite. This process is described in this chapter.

The second is to create a new database. This is described in the chapter Setting up a Lava Database.

The third is to configure and start the Lava Server. This is described in the chapter Mounting the Lava Server.

Once these three steps have been performed (which should take no more than 5 minutes in total) you will have a

fully functional Lava SQL Server, ready to accept connections.

Installing the Lava Server software suite

Whichever configuration is selected, it is necessary to install the Lava Server software suite completely. This is

achieved by executing the Lava Server Installable, LavaServerSetup.exe on the server itself. (If you do not

already have a copy of the setup executable, it may be obtained from www.lava-sql-com.) In order to perform a

complete install you will need administrative rights on the server, as manipulation of the service register will be

performed.

Follow the setup dialogs, completing all required entry fields.

Executable Folder

When asked for the executable folder, any desired folder for the executable files may be selected - the database

location is determined independently and will be selected later in the installation process. This folder, as with

any windows application, is the destination for the executable and DLL images used for the Lava Server. The

Lava Query and Lava Mimic executables will also, by default, be installed in this folder unless you specifically

disable the client applications through custom setup.

Lava Server Setup


Primary Database Folder

In the next dialog, the location for the primary database is required. Here, an appropriate folder (and drive) for

the primary database should be selected, which will have sufficient free storage space for the intended database.

In addition, it is advised to place the database on a newly formatted or recently defragmented drive, as this will

provide the best performance (it is of course possible to defragment the drive after installation, but this can only

be accomplished with the database dismounted, and defragmentation can therefore not be performed while the

database is in use).

Temporary Client Folder

The subsequent dialog requests a client (temporary) folder, which will be used if you install the Lava Query or

Lava Mimic applications, which require a temporary folder for the client database. Very little space is required

Executable folder selection

Primary Database Location


in the temporary client folder - around 20 Mb of free space should be adequate for 3 or 4 simultaneous client

sessions.

Note : If you are installing the Lava Server on NT 4.0 Windows Server (any version of Windows prior to

Windows 2000) you will not be able to run any of the Lava client applications (Lava Query, Lava Mimic, Lava

Desktop, Lava Blueprint) on this server. The Lava Server itself is specifically designed to be able to run

successfully on Windows NT 4.0 (with at least service pack 5 installed) but the interfaces used in the client

applications are not available prior to Windows 2000.

Server Address

The server address is only required if you are installing the client applications (Lava Query or Lava Mimic). If

not, you may ignore this dialog.

Component Selection

If in doubt, perform a full installation. The total size of the full installation is not very large (approximately

6 Mb) and this will ensure that you have a fully working installation. It is permissible to deselect the client

applications on NT 4 platforms, as these will not run on operating systems prior to Windows 2000.

Finalizing the Installation

Once all options and selections have been completed, selecting the Install button will complete the installation -

only a few seconds should be required.

Subsequent to installing the Lava Server software, you will need to create a primary database and select a server

strategy (executable or service).


Setting up a Lava Database

The first step in setting up a new Lava Database is to create the primary database. This is a very simple

operation, and should not take more than a minute or two.

Creating the Primary Lava Database

As with all true SQL server databases, it is necessary to create a database before the server can be started. The

Lava Database creation process is very simple and very quick. It involves selecting a single menu option, and

should take no more than a minute.

Starting the Lava Query Interface

Provided that you have installed the Lava Query system during the server installation, you merely need to select

the Lava Query option from the Windows Start Menu (the default group for the installation is Lava, unless you

changed this during the installation process).

The Lava Query system starts up unlinked to any database, and can be used in several modes - in this instance,

we will invoke database creation.

Creating a Lava Database

Once the Lava Query system has started successfully, you should see the following interface :

Creating the primary database is a single-step operation, and merely requires selection of a menu option, as

follows :

Lava Query Interface


Provided that you have specified a valid primary database folder (see Primary Database Folder) during the

installation process, and provided that a Lava Server is not currently mounted on an existing database at this

location, the database will create within a few seconds. After successful creation, you should see the following

confirmation :

Possible Creation Problems

There are a few problems that may occur during database creation.

No Datapath specification

If, for whatever reason, your Start Menu entry or shortcut to Lava Query has no Datapath parameter, you will

see the following error after attempting to create a database :

Creating a Database


In order to correct this problem, you will need to edit the properties of the shortcut you used to start the Lava

Query system. To obtain the property dialog, right-click on the shortcut or start menu option you used, and

select Properties from the pop-up menu. In the Target field, check that a valid DataPath entry is specified, as

in the following example :

For further information on command line parameter options, see the section Using Command Line Parameters.

Existing Lava Database

If an existing database is found at the specified DataPath, the creation process will display the following

confirmation dialog :

Note that if you confirm the creation (selecting the Overwrite existing option) any data in the existing database

will be lost. Should any data in this database be required for reference, you should first make a backup of the

appropriate schemas in the existing database. See Backup Procedures for information on how to back up data

from existing Lava databases.

Unspecified Creation Failure

The most likely reason for this form of failure is that you are attempting to create a database while another Lava

application (either Lava Server or Lava Query) is currently mounted to the same primary database.

Note that only one exclusive mount of any Lava database is possible at any one time. Exclusive mounts are

performed by both the Lava Server, and by Lava Query when an Exclusive Mount is performed. Should either

of these applications currently have the database open in Exclusive Mount, you will need to close the application

before attempting a Database Create at that Datapath.

Lava Query Datapath parameter


Creating a Lava Database on a Windows NT 4 platform

As the Lava Query system is unable to run on Windows NT 4, it will be necessary to adopt a different strategy

in order to create a database on a Windows NT 4 server.

There are two options which may be used to achieve database creation on NT 4 :

Creating an NT 4 database across the local network

If you have full create permissions on the Windows NT4 drive from another PC on the local network, you can

create the database across the network from a Windows 2000 or Windows XP machine by mapping the drive

and setting up the DataPath to the mapped drive.

You will have to install a copy of Lava Query on the network machine in order to create the database, and

specify the mapped drive during installation as the Primary Database Folder.

You may follow the instructions for creating a database as specified above, and the database will be created as if

you had executed the create on the server itself.

Creating an NT 4 database on a recent Windows release

If you do not have permission to create folders or files on the NT 4 server, or the server is not on the local area

network, another alternative is to install the Lava Server and Lava Query on a PC with a more recent release of

Windows (Windows 2000 or subsequent) and create the database on this machine. You may then copy the

entire database folder, including all subfolders and files, to any portable medium from which you can copy the

folder tree to the required server. Alternatively, you may FTP the folder tree to the server if you have FTP

access.

Be sure that whichever copy mechanism you use, even empty folders and null files are copied to and from the

portable medium (the same holds if FTP is used). One sure way to achieve this is to use the XCOPY command

from the windows command prompt in preference to mouse action on the Windows explorer (which is not

always to be trusted). The command

XCOPY [source path] [destination path] /E

will copy all files and folders to and from the portable medium. A newly created Lava database requires

approximately 3 Mb of storage space.

Note that if you copy the database via CD Rom, NT 4 will by default leave all files marked as Read-Only. You

must ensure that all files in the entire database folder tree have the Read-Only flag reset (i.e. permit writes), or

the database will not function after copying.

Successful Database Creation

If you have successfully created a Lava Database, you will see the following confirmation :

Once having accepted this notification, the new database is created and mounted. The database will be

completely void of data except for the initial system data which structures a Lava Database. You may now

create the users and schemas you require, and import data from foreign databases or restore backup sets created


previously.


Mounting the Lava Server

Before mounting the Lava Server, it is necessary to decide in which mode the Server is to be run. There are

several options available for installing and running a Lava Server. These range from options better suited to

short term evaluation, through to more thorough installations suitable for larger permanent installations.

The options are :

• Running the Lava Server as an executable

The Lava Server can be started up as a conventional executable, with command-line parameters.

Although the server functionality (in database server terms) will not be limited by this form of

operation, monitoring functions (see the section on the Server Monitor for further information) and

auto-start on re-boot (see the section on Primary Server Service for further information) will not be

available.

This option is generally suitable only for evaluation purposes, and is not recommended for permanent

installations.

• Installing the Lava Server as a service

The Lava Server can be installed as a standalone service. In this mode, monitoring functions (see the

section on the Server Monitor for further information) will not be available, but all other server options

will operate to specification.

Although this is a valid installation option, it is not recommended as the Monitor imposes almost no

load on the server and provides valuable additional reliability to the Server.

• Installing the Monitor and Server as services

In this mode of operation, both the Monitor (see the section on the Server Monitor for further

information) and the Server service will be fully operational with all functionality available with the

exception of the standby server (see the section on Standby Server Service for further information).

This option is suitable for small to medium-sized operations where the possibility of ten or twenty

minutes of downtime (to startup of a new server restored from daily backup) in the case of the

Windows server failing is acceptable. Note also that in this case data loss (in the case of hard-disk

failure) is possible in the period since the last backup, should the hard disk on the Windows server fail.

The following options are not available in the current release, but are listed for completeness :

• Available as of release 5.0, July 2005 : Installing monitor, primary and standby servers on one

Windows server

This is a fully functional installation, with all redundancy and monitoring facilities fully operational.

The only limitation to this form of operation is the possibility of hardware failure on a single server

rendering the server inoperable.

Generally, this option is recommended only for smaller sites as no true redundancy is provided by

running the standby server on the same Windows server as the Lava Primary Server. In addition, the

standby server does cause some additional loading on the server which may be undesirable for large

installations using a marginal server.

• Available as of release 5.0, July 2005 : Installing dual monitors with primary and standby servers on

separate Windows servers

This is the most elaborate operating mode, allowing full redundancy with hot standby on a separate


server which may be at any physical location as long as an IP link is available (permanently) to the

Primary Server.

This option is suitable for medium to large installations, or any site where no loss of data or downtime

of the Lava Server is acceptable. It provides complete redundancy with all data (up to the last

completely executed operation) available on the standby server.

Running the Lava Server as an Executable

The simplest option for the Lava Server is to run it as an executable. If you are in the process of evaluating the

Lava Database, this may be a good option for initial evaluation, as it is the easiest to use. In fact, provided that

you selected the appropriate primary database folder during installation, and you have successfully created a

Lava Database at that location as described in the chapter Setting up a Lava Database above, everything is

already set up to run the Lava Server as a standalone executable. The menu option loaded in the start menu

titled Standalone Primary Server will have been set up with the correct parameters, and all you have to do is

invoke the Standalone Primary Server from the start menu. This should start and mount the server, and the

following window should display :

You will see the mount mode (Primary Server) and the initial mount date and time displayed in the status bar of

the server window.

Once the server has mounted (which should take no more than a second or two) it is ready to accept connections,

and you may start any Lava Client set up to connect to the new server.

Note that if the database has not been created successfully, or if you have not closed the Lava Query system, the

server window will display as follows :

This indicates that the server was unable to mount the database, and is not operational. You will have to close

the server select Server / Dismount from the menu and the server will dismount and close), correct the problem

(complete the database creation process and / or close the Lava Query system) and re-invoke the server.

Note that you can only start one primary server on a given Windows server, and if you currently have a Lava

Server already running, starting a second Lava Server will also result in mount failure. In this case, you can

merely close the second Lava Server, the first will continue running without any effect.

Installing the Lava Server as a standalone service

In order to install the Lava Server as a service, you must invoke the Lava Control Panel. This may be achieved

by selecting the option Server Control Panel from the start menu. The Control Panel will appear as follows

without any advanced options selected :


In order to install the server as a service, you must select the correct option from the menu, as depicted below :

Note that you can only install the primary server once until or unless it is removed from the service registry

since installing. For this reason, the service menu will appear differently once the installation has been

performed :

You will note that in the above example, after installation of the service the Install option is disabled, and is also

indicated as completed through the tick to the left of the menu. The Remove option is now available, as the only

valid option once the Install has been performed.

Starting a Standalone Server

If you have chosen to operate the Lava Server as a standalone service, it may be started and stopped either from

the Windows Service Registry (Start / Settings / Control Panel / Administrative Tools / Services) or from the

Lava Control Panel, as follows :

Installing the Primary Server as a Service

Starting a Standalone Server


Again, as with the service installation menus, once the server has been started the only valid action is to stop the

server, and therefore the Start option on the menu is disabled.

Note that if you have not yet installed the Server service, the Start menu option will be disabled. See the

paragraph entitled Installing the Lava Server as a standalone service for information on installing the Lava

Server service.

If the Microsoft Windows Firewall is activated on your server, directly after the Lava Server is started Windows

will present the following dialog :

Since the Lava Server accepts connections via TCP/IP, it is necessary to Unblock the server in order for any

client to be allowed to connect to the server.

Lava Monitor installation

The Lava Monitor is a utility service which ensures uninterrupted server operation. The Monitor continuously

checks the server for operability, and performs appropriate control actions (Start or Stop) on the server as

required when the server is found to be inoperable. Due to the distributed nature of a Lava database, the Client

application always duplicates any information which the server needs with respect to any sessions the client has

open, and as a result the Client is able to refresh the information in the Server should a brief interruption in

service occur. For this reason, since the Monitor ensures that any interruption in service typically lasts only a

minute or so while the server is shut down and restarted, this effectively ensures continuous availability of the

server regardless of occasional server restarts.

For this reason, running the Lava Monitor is highly recommended - it consumes only a very small number of

resources on the server (CPU usage is almost nil, and total memory usage is typically under 4 Mb).

Lava Monitor options

In the current release of the Lava Server, the Monitor can only be run as a Primary Server monitor. As from

release 5.0, the option to run a Standby Server monitor will also be available.

Installing the Monitor service

As for installation of the Lava Server, to install the Lava Monitor as a service you need to invoke the Lava

Control Panel. To install the monitor, select the following menu option :

Windows Security Alert


If you have not yet installed the Lava Server as a service (which is required for correct operation of the monitor,

you will be prompted to install the Server at this point :

You should merely select the Install Server service button, and the Lava Server will be installed. If you do not

install the Server at this point, the Monitor will not be able to function.

Monitored Lava Server operation

Starting a Monitored Lava Server

To start a Monitored Lava Server, you only need to start the Lava Monitor service. This may be achieved by

selecting the following menu option from the Lava Control Panel :

Note that if you have not yet installed the monitor service, the Start menu option will be disabled. See the

paragraph entitled Lava Monitor installation for information on installing the Monitor service.

As with the service installation menus, once the Monitor has been started the only valid action is to stop the

Monitor, and therefore the Start option on the menu is disabled.

Once the Monitor has been started, it will automatically start the Lava Server. Provided that the Primary

Database has been correctly created (see the section Creating the Primary Lava Database for information on this

process), the Lava Server will mount within a few seconds, and you should see the following windows appear :

The upper window of the two is the Monitor, which indicates in its status bar that the primary Lava Server is

running and accepting connections.


If the Microsoft Windows Firewall is activated on your server, directly after the Lava Server is started Windows

will present the following dialog :

Since the Lava Server accepts connections via TCP/IP, it is necessary to Unblock the server in order for any

client to be allowed to connect to the server.

Service Installation Problems

In order to be able to install the Monitor or Sever as services, you need to have administrative rights on the

server. If this is not the case, attempting to install the services will fail and return an error message.

If you do have the required privilege, you may find that the Windows Service window

(Start>Settings>Administrative Tools>Services) will hold (lock) the service registry, preventing installation or

removal of services. If this is the case, merely close the Windows Service window and it will release the

registry, allowing installation of the service.

Standby Lava Server options

Note : The Lava Standby Server is not available in the current release, and will only be included in release

5.0 planned for July 2005.

Windows Security Alert


Controlling a Lava Server

Depending on the operation mode selected for mounting the Lava Server, the server is controlled either directly

or through the Control Panel.

Note that before you can mount the Lava Server, you must have successfully created a Primary Database - see

the section section Creating a Primary Lava Database for information on this process.

If you are running the Lava Server as an executable (without installing the server as a Windows service) it is

controlled directly, as described in Controlling the Lava Server as an Executable below.

If you have installed the Monitor and / or the Server as services, they are controlled as described in the section

Lava Control Panel

Controlling the Lava Server as an Executable

If you have chosen not to install the Server as a Windows service, the Server is controlled by executing and

exiting the Server directly.

Even if you have installed the Server as a Windows service, it is still possible to run it as an Executable if you

wish to do short tests. Note, however, that the redundancy offered by the Monitor is not available in this mode

of execution.

Mounting an Executable Server

To mount an executable Lava Server, you merely have to start the Server as you would any Windows

application. Note that in order for the Server to start (mount) correctly, a Lava Database must exist at the

specified Primary Database folder. For information on creating a Primary Database, see the section Creating a

Primary Lava Database above.

Once a valid Primary Database exists at the correct location, the Server is merely executed. This may be

achieved through the Start menu, from Start>Lava SQL>Standalone server if you have used the default

installation group.

Provided that there is no other application (either another server or the Lava Query system) mounted to the

specified Primary Database, the server will mount within a few seconds and be ready to accept connections. The

Lava Server window should appear as follows after a successful mount :

Should the server not mount successfully, check that the Primary Database was correctly created and that no

other server or Lava application is mounted to the same Primary Database.

Dismounting an Executable Server

In order to dismount a Lava Server, the Server menu is used.


Select Dismount & Exit, and the Server will close down any current client connections and exit. Server

dismount will take approximately 20 seconds.

If you dismount the Server while clients are connected, these clients will run unimpeded for a short while

without access to the Server. In order to avoid loss of functionality in any of the clients over time, the Server

should be re-started as soon as possible to allow the clients to re-connect - if this is done soon enough (for well

designed clients a few minutes should be fine) no degradation of client functionality should result.

Lava Control Panel

The Control Panel allows easy control over a standalone Server service, or the Lava Monitor (if monitored mode

was selected during configuration of the Server). Starting the Control Panel may be achieved through the Start

menu (Start>Programs>Lava SQL>Server Control Panel).

Controlling a Standalone Server

Once the Server has been successfully installed as a Windows Service (see the section Installing the Lava Server

as a standalone service for details), mounting and dismounting the Server is very simple.

Mounting a Standalone Server

To mount a standalone Server, merely select the Start Primary Server option from the Control Panel menu, as

follows :

Note that this menu option will only be available if the server is currently dismounted (stopped) and has

correctly been installed as a service. For information on installing the Server as a Windows service, see the

section Installing the Lava Server as a standalone service.

This will start and mount the Lava Server, and should result in a Server display as follows :

Should the server not mount successfully, check that the Primary Database was correctly created and that no

other server or Lava application is mounted to the same Primary Database.

Once mounted, the Server window can be minimized to the Windows System Tray by clicking on the minimize

button near the top right-hand corner of the window :

Dismounting a Standalone Server

Dismounting the Server in this mode of operation can be accomplished in one of two ways :

• Stopping the service through the Control Panel


The control panel can stop the Lava Server which results in a dismount. This is achieved through the

Control Panel menu, as follows :

Note that this menu option will only be available if the Server is started (mounted) - if not, or if the

Server has not been installed, the menu option will be disabled.

• Dismounting and Exiting via the Server menu

Alternatively, the server may be dismounted via the server’s own menu, as follows :

Select Dismount & Exit, and the Server will close down any current client connections and exit. Server

dismount will take approximately 20 seconds.

Controlling a Monitored Server

If you have installed both Server and Monitor (the recommended mode of operation) primary control over the

Monitor / Server pair is achieved through the Control Panel.

To start the Monitor, select the Start Primary Monitor option from the Server Control Panel menu, as follows :

If this menu option is disabled, either the Monitor is already running or it is not yet installed. To install the

Monitor, see the section Installing the Monitor service.

Once started, the Monitor will immediately start and mount the Primary Server, after which the Monitor control

and information window should appear as follows :

The status bar indicates the current status of the Lava Server. In the above case, the status indicates a fully

functional server. The count displayed is obtained directly from the server’s dispatch thread, and indicates that

the server is functioning and dispatching transactions. If the server should fail (or cease to process transactions),

for whatever reason, the Monitor will first ensure that the service for the Lava Server has been stopped, and then

re-start the Lava Server automatically.

Stopping (Dismounting) a Monitored Server


If you stop (dismount) a Monitored Server using the Server Control Panel, the Monitor will detect this as a non-

functional Server and immediately re-start the Server. In order to stop a Monitored Server, you need to do one

of two things :

• Stop the Server through the Monitor

The preferred method for dismounting a Monitored Lava Server is through the Monitor itself. This is

achieved through the Monitor menu, as follows :

Note that while a monitored Server is running, the only available action from the Monitor menu is to

stop the Server. The fact that the Server is currently running is indicated by the check mark next to the

disabled Start Server menu option.

Once the command has been issued, the server will commence the dismount. This will be indicated on

the Server status bar, as can be seen here :

Dismounting the server will take approximately 20 seconds, at which point the Server window will

close.

In addition, the Monitor will indicate that the Server has been disabled, as follows :

• Stop the Monitor using the Server Control Panel.

If the Monitor is stopped through the Server Control Panel, this will cause the Server to dismount as

well. During the dismount process, the Monitor will display a status message in the status bar to

indicate the current action, as follows :

Once the dismount of the Lava Server has been completed, the monitor window will close.

Re-starting a Monitored Server

If you have stopped the server through the Monitor menu, and the Monitor is thus still active, the Server can be

re-started through the Monitor menu, as follows :


This option will re-start and mount the Lava Server, and re-connect the Monitor.

If you have stopped the Monitor through the Server Control Panel, the Monitor and Server must be re-started

through the Control Panel as described in Controlling a Monitored Server above.


Lava Query System

The Lava Query System fulfills several functions in a Lava Server environment. The most important of these

are :

• Creating the initial Lava Database

Unless custom code is written to create new Lava Databases, the Query System is the easiest way to

perform this task. See Creating a Lava Database for further information.

• Performing ad-hoc queries

General-purpose SQL queries may be executed with the results displayed in a data grid which supports

export to Excel spreadsheet format

• Performing ad-hoc updates

Where specific updates or modifications need to be performed to a Lava Database which are not

possible from a given application, the Query system allows these updates to be performed via SQL,

while the results can be checked using an SQL query subsequently. Commit or Rollback may be

selected depending on the success of the update.

• Testing and developing SQL statements

The interface provides a useful mechanism for the evaluation, optimization and checking of SQL to be

used within an application

• Examining the Lava Event Log

The Event Log provides a wealth of detail on errors (programming and otherwise) encountered during

interface to the Lava Server. Details on user, date, time and specific error codes or code sequences may

be obtained to assist in evaluating and tracing application errors.

• Backup and Restore

While schema backup can be performed under program control from any Lava Client, it may still be

more convenient to be able to execute any required backup on any Lava schema from the Query

system. Restore operations can only be done through the query system unless custom code is written

for the purpose, as the database must be mounted in Exclusive mode to be able to perform a backup

restore, which the Query system is capable of doing.

initial text file load

event log

disable test interface option from Database menu

disable parser / load syntax

delay load network servers; button to load

remove “database files” option from Database menu

remove file / new option

The Lava Query System as a Lava Client

Lava clients function (from the users’ perspective) identically to any other Windows application - with some

additional functionality (notably groupware facilities) and typically at higher speed. The only difference the

user may experience between a Lava client and a conventional Windows application at initial encounter is the

requirement to log in (which can be relegated to command-line parameters if the application environment is

secure) since a Lava Client must be fully identified to the Lava Server for both security and auditing reasons


Connecting to a Lava Database

In order to activate the query interface, it is necessary to connect to a Lava Database. The query system allows

this connection to be made in one of two ways.

Connecting to a Lava Server

The default connection method is as a standard Lava Client, connecting to an existing Lava Server. This is

achieved by activating the connect dialog, by clicking on the Connect button, or pressing Alt+C on the keyboard

as follows :

This will activate the connect dialog, which appears as follows :

To connect to a specific server, enter the required username and password in the fields provided, and specify the

server either by typing in the server name or IP address, or by clicking on the Servers button to load a list of

available servers on the local area network and dropping the list to select the sever. Once the server list has been

loaded, you may select a Lava Server by dropping the list.

The username and password may be entered in the fields provided, or, if you are operating in a secure

environment, they may be specified on the command line as follows :

LavaQuery /user=system /password=manager

If you wish, you may specify only the username, omitting the password. This will result in requiring only the

password to be entered in the connect dialog. For further information on command line parameters, see the

section Using Command Line Parameters.

Once all fields have been completed, you may click on the completion button ( % ) which will result in a Lava

Server connection if all the connect parameters are correct.

Connecting Exclusive

In order to perform any data restore action it is necessary to connect exclusively to the database. No data restore

can be performed through a Lava Server. Restoring data is a disruptive process and therefore the possibility of

any client connection to the database must be completely ruled out before a restore can be performed.

This is achieved through connecting exclusively to the database. This implies that the Lava Query system has


sole access to the database, and by implication the Lava Server must be stopped (dismounted) before an

exclusive connection from the Lava Query system can be attempted.

The database path for the Lava Database to be used for exclusive connection must be specified via the command

line, as follows :

LavaQuery /DataPath=S:\Lava\Primary

If you have specified all paths requested during the installation process, this will already have been specified for

you. For further information on command line parameters, see the section Using Command Line Parameters.

If the drive and folder specified are on a network drive situated on a server, the user must have complete rights

on that folder (permission to delete and create folders and files) in order for a restore to be performed.

For information on performing data restore operations, see the section Restore Procedures.

Connecting through SQL

If you prefer using typed commands, you may connect to a Lava Server using SQL. The command syntax is as

follows :

CONNECT SERVER servername USER username PASSWORD passwordCONNECT SERVERIP serverIPaddress USER username PASSWORD passwordCONNECT EXCLUSIVE USER username PASSWORD password

The first option will connect to a server visible on the local network.

The second option can connect to any server with an accessible IP address.

The third option performs an exclusive connection to the database specified in the /DataPath command line

parameter - for further information on command line parameters, see the section Using Command Line

Parameters.

Using Command Line Parameters

Several optional and some mandatory command line parameters are used to determine certain settings in the

Lava Query system. Note that if you have completed all the inputs to the install process correctly, all required

parameters will have been completed for you.

Setting Command Line Parameters

Should you wish to alter the command line parameters for Lava Query, or should you require additional optional

parameters which were not set by the installation process, you need to access the property dialog for Lava

Query. To obtain the property dialog, right-click on the shortcut or start menu option you used, and select

Properties from the pop-up menu. In the Target field, modify or add the parameters as required.

Lava Query Parameters


The following parameters are provided :

Database Path

The Database Path is the path (fully qualified, drive and folder) to the Lava Database to which Exclusive Mount

is to be performed. For information on Exclusive Mount, see the topic Connecting Exclusive.

The database path for exclusive mount must be set using a command line parameter - there is no equivalent

setting in the Lava Query system via any dialog.

This parameter is optional, but is required for Exclusive Mount. Should you not have the requirement to

perform data restore operations, this parameter may be ignored.

/DataPath=S:\Lava\Primary

Client Database Path

The Client Database Path is the path used to establish the Client database when connecting to a Lava Server.

Since the Lava Query system is a fully functional Lava Client, it creates a complete Client Database at connect

time, which is established at the path specified.

This parameter is mandatory - it is not possible to perform a connection to a Lava Server unless the path

specified is valid, and sufficient space (approximately 3 Mb of free space) exists on the drive specified.

/ClientPath=S:\Temp

IP Address for Server

Should you wish to connect to a server which is only accessible via an IP address (i.e. not visible on your local

network), in order for this server to appear in the server drop list in the connect dialog you must specify the IP

address via the command line parameter below.

This parameter is optional, and is only required for dialog connection to IP - specified servers. You may connect

to any server, IP or otherwise, via SQL whether or not this parameter has been specified.

/ServerIP=127.0.0.1

Backup Folder

The Backup Folder is the full path to the folder to be used to store and retrieve backup data sets.

The Backup Folder parameter is optional, and is only required should Backup or Restore operations be required.

/BackupFolder=S:\Lava\Backup

Username and Password

Should your workstation be located in a secure environment, and only you or trusted staff have access to your

workstation while your Windows user is logged in, you may set the username and password for your default

connection via these command line parameters. In less secure environments, the password may be omitted,

requiring this to be entered via the connect dialog.

These parameters are optional, and should not be specified unless your workstation is secure.


/User=system /Password=manager

Issuing a SQL Command

The Lava Query application has a number of important areas presenting information and allowing command

entry. These are depicted below :

1 Schema Selection

The Schema drop list presents a list of all schemas present in the database, and allows selection of a

specific schema which filters the table list (see 2 below). Note that selecting a schema from this list

does not alter the default schema for the connection.

2 Table list

The table list presents a list of all tables in the selected schema (see 1 above). Selecting a table from

this list presents a list of columns for the table in the column list (see 3 below).

3 Column list

A list of columns for the table selected in the table list (see 2 above)

4 Command history

The command history list presents a list of recently executed SQL commands. Clicking on this list

allows selection of the command, which is placed in the SQL command area for modification or re-

invocation.

5 Result grid

The result grid is a datagrid which displays the results of the last SQL command issued (if any).

6 SQL command area

This text area allows entry and modification of SQL commands which may be executed by clicking on

the SQL command button just above the area.

Each of the areas may be re-sized by clicking on the resizer between any two areas and dragging with the

mouse.

Disconnecting and Dismounting

The Lava Query system may be disconnected from a given database either by connecting to another database

server, or by closing the application. In both cases the Client database utilized during the connection is released,


and the space is free for re-use.



All regular administrative tasks required on a Lava Database may be achieved through use of the Lava Query

system. For an introduction to the Lava Query system, see the chapter Lava Query System.

Under most circumstances, a Lava Database needs little or no administration - with the exception, of course, of

regular backups. Generally, the database does not need monitoring because of space constraints - provided the

drive housing the database has sufficient free space, the database will automatically expand to provide for data

requirements.

General Administration

A Lava Database and the Lava Server will be largely self-administrating, with the obvious exception of data

backup. Apart from this (documented separately below), there are only a few tasks the administrator may wish

to perform from time to time.

The two issues which are worth checking are the system event log, and drive space maintenance on the database

drive.

Drive Free Space

The database drive (the drive partition or logical drive the Lava Database is positioned on) must have sufficient

free space to provide for anticipated database growth over a reasonable period, such as a week or two at least. It

is difficult to provide a method for estimation of required drive space, as this will depend on data entry rates,

imported data sets, use of the partition by other applications, and possibly other factors such as temporary files

created by various applications or even the operating system.

Given the inexpensive nature of hard disk space, it is probably advisable to ensure that a few gigabyte of spare

data at least is available on the database drive.

Drive Fragmentation

Although the Lava Server should, if properly utilized as a Lava distribution server (and not in conventional

Client Server mode) only experience nominal demand for data. Nevertheless, it is important to keep the

database drive / partition relatively free of fragmentation.

This may be achieved by using the defragmentation utility included in the operating system, but this can be very

time-consuming. The quickest way to achieve 100% defragmentation is to dismount the Lava Server, copy the

database (and any other data which needs to be preserved) off the database partition to a temporary drive, then

re-format the database partition (a quick format will suffice), and copy the database back. Such a reformatted

partition is completely defragmented in the shortest possible time.

Event Log

The server event log provides an audit trail of errors and warnings accumulated in the server since creation. The

event log may be obtained from the Lava Query System by selecting Database / Event Log from the main menu.

A sample of the Lava Event Log is provided below.


The columns provided in the event log listing are :

# : The event log entry number. If a positive number is returned in a return code from

the Lava database kernel or a Lava utility procedure, this number represents a log

entry number.

Event : The short description of the event.

Description : A more complete description of the event.

Object ID : The Object ID of the object affected by the event, if any

Object : The name of the object affected, if any

Procedure : The Lava System procedure name, indicates the procedure which detected / reported

the error. Used primarily for queries or problem reports directed to Tesseract

concerning the error.

Module : The Lava System module title of the module containing the procedure which detected

the error. Used primarily for queries or problem reports directed to Tesseract

concerning the error.

Severity : (unused at present) indicates the severity of the error.

Prev. # : Indicates the previous event log entry if a chain of error events were logged.

VDT : The date / time of the event. All VDT displays are in the local time of the current

workstation (presuming that the workstation has been configured correctly in its

regional settings).

For a complete listing of Lava error codes, see the section Appendix I : Lava Error Codes in the Lava

Technical Reference, available in Acrobat PDF format from the Tesseract website (www.tsrg.net).

Backup Procedures

A comprehensive backup mechanism is included in the Lava Database kernel. The Lava Query System provides

a backup interface which allows backups to be made from any workstation which can connect to the Lava

Server. Speed of backup will depend on the bandwidth to the server and the amount of data to be backed up.

The resulting backup set for a schema is written to disk as one or more Windows files, depending on the nature

of the backup. The data portion of each backup file is compressed (and may be encrypted).

In addition to the standard backup facility provided within the Lava Query System, it is possible to call the

backup API directly from program code, allowing virtually any combination of tables and schemas to be placed

in single or multiple backup files. See the Lava Technical Reference for details on the API for backup

procedures.

To perform a backup from the Lava Query System, ensure that the Query System is connected to the correct

Lava Server as a client, and select the backup / restore interface from the main menu through the Database >

Backup / Restore option.

The Backup and Restore interface should appear, as shown below.

Lava Event Log


Before any configuration has been done, the backup structure tree will be empty. In order to perform a backup,

selections must be configured into the tree to define the content of the required backup.

A backup may consist of one schema (which may be configured as a backup Set), or more than one schema (in

which case a backup Group must be used).

Backup Sets

A backup set consists of only one schema. If, for example, you wish to backup the data for a specific

application, the tables for the schema will typically be contained in one schema, and in this case a backup set

may be used.

To configure a backup set, first click on the Backup Set row in the tree. The row will highlight, and a create

icon will appear next to the row. Clicking on this icon will create a blank backup set entry, as follows.

Enter a description for the backup set by clicking in the description column. Select a schema for the backup set

by first clicking in the column for the schema, then by clicking on the lookup button placed at the right hand


edge of the column, as indicated below. Select the desired schema to back up from the list presented.

For a complete schema backup, this is all that needs to be specified. If you do not wish to specify individual

tables, skip the next paragraph and continue to the paragraph on performing backups.

Specifying individual tables in a Backup Set

Should you wish to backup only one or more specific tables from a schema, omitting all other tables, you may

do this by first expanding the row for the backup set (click on the + icon to the left of the row), then clicking on

the row titled “Backup Objects”. A create icon will appear to the left of the Backup Objects row, which allows

creation of table entries as follows :

A specific table may be selected by clicking in the column labelled “Object”, then clicking on the lookup button

to the right of the column.


The column may be widened (as in the above example) by clicking on the column divider and dragging to the

right, which will allow more visibility on the table names which are presented in Schema.Table format.

More tables may be added to the backup set by clicking on the create button to the left of the Backup Objects

row label.

Backup Groups

Should you wish to include more than one backup set into a backup, it is possible to do this by constructing a

Backup Group. Similarly to constructing a Backup Set, click on the row labelled “Backup Groups”, then click

on the create button which appears to the left of the label. Enter a title for the backup group in the Label

column, then create Backup Set entries within the Backup Group by expanding the group entry, clicking on the

“Backup Sets” row, and clicking on the create button to the left of the label. Any number of backup sets may be

added to the backup group in this way. Each of the backup sets is configured as described in the paragraph

Backup Sets above.

Performing Backups

To perform a backup, expand the appropriate tree (Backup Groups or Backup Sets, depending on requirement),

and click on the row for the required backup set or backup group. Once the row is highlighted, you may right-

click on the row, which will present a pop-up menu as shown below. Select the option “Execute Backup Set” or

“Execute Backup Group”, depending on the type of backup entry selected. This will execute the backup, which

will be stored in the nominated backup folder.


The backup folder is specified in the command line parameters for the application- see Using Command Line

Parameters for detailed information on setting command line parameters in the Lava Query System).

Note : If updates are being performed on the specified schema during the backup, it is possible that the backup

set could be inconsistent in that a set of updates to multiple tables relating to a given master entry could be

incomplete at the time of the backup. Although this is unlikely in small tables, it is best to perform backups

when no updates are being performed on the database. If consistency in the backup is particularly important, it

may be best to perform the backup after exclusively mounting the database, as with the restore procedure

described below.

Once the backup is complete, a dialog will appear informing you of this fact. At this point, a backup file with a

generated filename may be found in the backup folder. For example, a backup of the Util schema could appear

as :

Util 2004.12.8 13_54_57.389.lbs

The name specifies the schema contained (Util in this case), the date and time of the backup (in local time), and

the extension lbs (Lava Backup Set).

Performing Repeated Backups

Once a particular backup set or group has been configured in the way described above, backups may be

performed repeatedly using the same configuration. In other words, you only need to configure a particular

backup set or group once, following which any number of backups may be performed by right-clicking on the

backup row. Each backup performed using a given backup configuration will be logged to the database and may

be seen by expanding the Set Backup Log subtree. An example of a backup log entry is provided below.


Restore Procedures

Unlike the backup procedure, a restore can only be performed with the database mounted exclusively. This is to

avoid corruption or inconsistency of data during the restore process as a result of updates to tables included in

the backup set. The process for mounting the database exclusively is described below.

Shutting down the Server

Server running standalone

If you are running the Lava Server in standalone mode, you need to dismount it using the menu option

Server>Dismount & Exit. The server will dismount within about 15 seconds.

Server installed as a service

If you are running the Lava Server as a service, the appropriate action depends on whether you are also running

the Lava Monitor or not.

If you are running an unmonitored server (without Lava Monitor) you may dismount the server directly using

either the server menu (Server>Dismount & Exit) or through the Lava Server Control Panel (Server>Service

Control>Stop Primary Server). In either case, the server will dismount in about 15 seconds.

If you are running a monitored server, the easiest way to dismount the server is through the Lava Server Control

Panel, using the menu option Monitor>Service Control>Stop Primary Monitor. In this case, both the server and

the monitor will dismount within about 20 seconds.

Using Exclusive Mount

Once the Lava Server has been dismounted, you may mount the Lava Query System in Exclusive mount. In

order to do this, you must have adequate access (either directly on the server or through a network mapped

drive) to the database drive and folder. Your Database Path parameter to the Lava Query System must be set

correctly, and you must have comprehensive privileges to the database folder, including create file and create

folder privilege.

For details on mounting the Lava Query System exclusively, see Connecting Exclusive.

Performing a Restore

Once you have a successful exclusive mount to the server database, you may perform any restore actions

required.

First, invoke the Backup and Restore window from the main menu through the Database > Backup / Restore

option.


To restore a particular backup, expand the tree to display the Set Backup Log (or Group Backup Log) and right-

click on the required backup log entry. Select the Restore Backup option from the popup menu presented, as

shown below.

Note that any tables contained in the backup set will lose any data they currently contain, which will be replaced

by the data specified in the backup set. Should you have any data in these tables which you wish to retain, you

should first perform a backup of this data before proceeding with the restore.

Once the restore has been completed, the database will automatically perform a dismount / remount cycle in

order to correct kernel references to the restored schema. This is announced through the following message :

On confirming the message, the database will dismount and re-mount - this should take no more than a few

seconds, following which any subsequent operations or further restores may be undertaken.

Re-mounting the Server

Once the restore has been successfully concluded, you may dismount the Lava Query System and restart the

Lava Server. For information on mounting the Lava Server, see the chapter Mounting the Lava Server.

Importing a Backup

If the backup required for restore was not performed from the database to which you wish to restore, you must

first import the backup into the backup / restore system.

Right-click on either the Backup Groups or Backup Sets row, and from the popup menu select to import either

a backup group or a backup set, depending on requirement. Once the backup has been imported, follow the

same procedure as described above, Performing a Restore.


Importing Data

The Lava Query System provides for the import of data from any database providing an ODBC driver, and

supporting basic SQL.

In the current release of the database it is necessary to mount the Query System in exclusive mode in order to

import data. In order to do this, you will first have to shut down the Lava Server if it is mounted - see Shutting

down the Server for information on this process. For details on mounting the Lava Query System exclusively,

see Connecting Exclusive.

Performing an Import

To invoke the Data Import dialog, select File > Import from the main Query System menu. The dialog depicted

below will appear :

Select the database source using the DB Source drop list - this will list all the available ODBC sources on your

workstation. The Connect button will invoke the connection dialog presented by the ODBC driver selected -

completion of this connection dialog is driver specific, and you may have to refer to the documentation for the

source database or request assistance from the Database Administrator to determine the correct parameters.

In order to perform a data import, a valid connection to the source database must be established. If the

connection is valid, the Connection and DB Name fields will be filled in subsequent to connecting - these values

are determined from the source database ODBC driver. If the connection fails, these fields will remain blank.

Data Import from ODBC


In the example below, a valid connection to an Oracle database is established - note the values indicating this

connection.

Once a connection has been established, you need to select the correct schema for the imported data table. The

import will create a Lava Table in the schema selected - by default the schema is Scratch (a temporary schema)

- you may wish to change this. Be sure that you have adequate permissions on the schema selected - you will

need CREATE permissions in order to create the imported table.

Specify the required name for the imported table in the Table field - the default is ImportTable; you will

probably want to change this.

By default, the import dialog flags Override existing content - this means that even if a table by the specified

name exists in the selected schema, its contents will be replaced by the imported data. Note that in order for this

flag to function, you require DROP permission on the selected schema.

Finally, enter an appropriate SQL select command (such as the example in the dialog above), ensuring that the

select entered will provide the required data.

Once all parameters for the import - including the SQL select - have been specified, click on the Import button.

The select command will be passed to the source database via the ODBC driver, and any data resulting from the

select will be imported into a newly created table as specified.

On completion of the import process, the resulting data table will be displayed in a data grid at the bottom of the

import dialog.

Note that as column formats for a given table grid are saved each time a table is

viewed, if you import a particular select set into a table, then modify the select and re-

import to the same table name, the format for the data displayed is likely to be

incorrect. If you suspect that this is the case, reset the format for the grid by right-

clicking on the grid header row and select Reset Format from the pop-up menu as

depicted to the right :


Import Results

A data import as described above results in a permanent data table within the schema nominated. This table may

be used as with any other Lava table, and will be included in any backup for the schema.

In order to render the table fully usable, standard version columns (row status, ID and VDT) are added to the

table in order to permit transaction frames on table updates.



Client-Server

Distributed Client

Server Monitor Service

Primary Server Executable

Primary Server Service

Standby Server Service

Date post:	17-Jun-2020
Category:	Documents
Upload:	others
View:	6 times
Download:	0 times

Qubik Lava Installation and Administration Guide Installation and Administration... · • Startup...

Documents