qubik lava installation and administration guide installation and administration... · • startup...
TRANSCRIPT
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
Manual Scope and Target Audience
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 :
Manual Scope and Target Audience
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.
Installing the Lava Database
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.
Administering a Lava Database
This section describes regular administration required by a Lava Database. The most important of these is that
of regular data backup.
Importing Data
Manual Scope and Target Audience
Describes methods for importing data into a Lava Database from an ODBC data source
Principles of Operation
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.
Manual Scope and Target Audience
Installing the Lava Database
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
Manual Scope and Target Audience
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
Manual Scope and Target Audience
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).
Manual Scope and Target Audience
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
Manual Scope and Target Audience
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
Manual Scope and Target Audience
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
Manual Scope and Target Audience
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
Manual Scope and Target Audience
previously.
Manual Scope and Target Audience
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
Manual Scope and Target Audience
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 :
Manual Scope and Target Audience
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
Manual Scope and Target Audience
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
Manual Scope and Target Audience
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.
Manual Scope and Target Audience
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
Manual Scope and Target Audience
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.
Manual Scope and Target Audience
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
Manual Scope and Target Audience
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
Manual Scope and Target Audience
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 :
Manual Scope and Target Audience
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.
Manual Scope and Target Audience
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
Manual Scope and Target Audience
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
Manual Scope and Target Audience
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
Manual Scope and Target Audience
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.
Manual Scope and Target Audience
/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,
Manual Scope and Target Audience
and the space is free for re-use.
Manual Scope and Target Audience
Administering a Lava Database
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.
Manual Scope and Target Audience
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
Manual Scope and Target Audience
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
Manual Scope and Target Audience
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.
Manual Scope and Target Audience
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.
Manual Scope and Target Audience
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.
Manual Scope and Target Audience
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.
Manual Scope and Target Audience
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.
Manual Scope and Target Audience
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
Manual Scope and Target Audience
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 :
Manual Scope and Target Audience
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.
Manual Scope and Target Audience
Principles of Operation
Client-Server
Distributed Client
Server Monitor Service
Primary Server Executable
Primary Server Service
Standby Server Service