Lava Administrator - Lava Distributed SQL

Document Sample
Lava Administrator - Lava Distributed SQL Powered By Docstoc
					 Qubik Lava
 Installation
     and
Administration
   Guide
                                  Table of Contents

Introduction
      Manual Scope and Target Audience
      Using This Reference
      System Requirements
      Reference 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 Database
      Installing the Lava Server software suite
               Installation Type
               Destination Location
               Primary Database Folder
               Temporary Folder
               Lava Server Address
               Executing the Installation
               Activating the Database
      Creating the Primary Lava Database
               Start the Lava Administrator
               Creating a Lava Database
               Possible Creation Problems
               Dismounting an Executable Server
               Controlling a Monitored Server


Lava Administrator
      Functionality In Brief
      Status
               Operating Modes
      Defaults
      Launch
               Create Database
               Backup
               Restore
               Activate
               Add License
               SQL Query
               Stream Elements
               Blueprint
      Parameters
      Triggers
               Scheduled Processes
               Triggers


                                                  i
     Services
            Server Modes
            Running the Lava Server as an Executable
            Installing the Lava Server as a standalone service
            Starting the Lava Server when installed as a Service
            Running a Lava Server
            Installing the Monitor service
     Monitored Lava Server operation
            Starting a Monitored Lava Server
     Service Installation Problems
     Users
     Sessions
     Schemas

Lava Query System
     The Lava Query System as a Lava Client
     Connecting to a Lava Database
            Connecting to a Lava Server
            Connecting Exclusive
     Using Command Line Parameters
            Setting Command Line Parameters
            Database Path
            Client Database Path
            Server address
            Backup Folder
            Username and Password
     Issuing a SQL Command
     Disconnecting and Dismounting

Administering a Lava Database
     General Administration
            Drive Free Space
            Drive Fragmentation
            Event Log


Backup and Restore
     Backup Procedures
            Backup W izard
            Manual Backup Configuration
                   Backup Sets
                   Specifying individual tables in a Backup Set
                   Backup Groups
                   Performing Manual Backups
                   Performing Repeated Backups
     Restore Procedures
            Shutting down the Server
            Restore W izard


Importing Data
                                                  ii
      Performing an Import
      Import Results

Principles of Operation
      Client-Server
      Distributed Client
             Fully Distributed Tables
             Distribution On Demand
             Interruption of Server Connectivity
      Primary Server as an Executable
      Primary Server as a Service
      Server Monitor Service
      Satellite server
      Standby Server




                                                   iii
                                  List of Illustrations
Lava (4)
Executable folder selection (5)
Primary Database Location (5)
W indows Security Alert (27)
W indows Security Alert (29)
Lava Query Parameter (32)




                                            iv
                                                                       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 W indows NT 4 with Service Pack 5 installed.
The server will install and run on the following operating systems :
        W indows NT 4 (with at least Service Pack 5), 2000 or XP, or W indows Server 2000 or 2003.

The client applications included in the server installation (Lava Query and Lava Mimic) will only run on
W indows releases from W indows 2000 onward.
The clients are tested on :
         W indows 2000 or XP, W indows 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

Specifies processes for administering and configuring a Lava database, including the primary server, standby
server and satellite server configuration and setup. This chapter is important for users intending to manage the
database and peripheral servers for other users or for their own user.
                                                                     Manual Scope and Target Audience

Importing Data

Simple import of data from other databases (without conversion) is described here. This applies only to
relatively small data tables (no larger than2 or 3 million rows).


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
Although other options exist, this chapter will focus on the installation of the Qubik Blueprint Build, which is
the quickest and easiest way of installing the Lava Database and the Lava System software.

In order to perform a complete install you will need administrative rights on the server, as manipulation of the
service register will be performed. Please ensure that this is the case before continuing.

Once the latest build has been downloaded from www.lava-sql.com, execute the main install
QubikDevelopmentSuite.exe. This will allow installation of only server software, or of the entire development
suite.




                      Lava Development Suite Setup


Follow the setup dialogs, completing all required entry fields. The following paragraphs list the important steps
during the installation process.


Installation Type

You should choose “Both Server and Blueprint”. Once more familiar with the Lava system, and when installing
for specific purpose at a given site, you may select other options - for now, install the full suite.
The options are :
•        Primary Server Only
                                                                        Manual Scope and Target Audience

         This option may be used when you are familiar with the system and are installing specifically for a
         server, where the machine will not be used for development under any circumstances.

•        Blueprint Only
         The correct choice for workstation installs in a multi-user environment, this option will not install the
         server software and will not provide a sample database.

•        Both Server and Blueprint
         You should choose this option for your first installation. This will install the server, a sample database,
         and the full development environment - this will allow you to evaluate the system in the easiest and
         quickest way.



Destination Location

The system may be installed on any folder / drive with adequate free space (100 Mb is recommended for
evaluation purposes - more if you wish to do serious testing with a larger database).

The installation will default to the Program Files folder within the W indows installation, but may be redirected
to any desired location. If you wish to do serious testing, it is recommended that you place the installation on a
drive which is defragmented and has good performance.




                         Executable folder selection



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 - defragmentation cannot be performed effectively while the
database is in use).
                                                                          Manual Scope and Target Audience




                        Primary Database Location



Temporary Folder

The temporary folder is used for client applications (including the Blueprint development environment) as
temporary storage. It may be placed anywhere - the default will be fine if you have no specific preferences.


Lava Server Address

The installation will, by default, insert the name of the current PC. If this is your server installation, this default
is correct. If you are installing a second client, you will need to modify this to specify a valid address for the
Lava Server.


Executing 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.


Activating the Database

You will need a license key to use the new installation. During the installation process, the following dialog will
be presented :
                                                                      Manual Scope and Target Audience

You may at any time obtain an extended evaluation license from Qubik Digital, but for initial evaluation
purposes you may simply click on the Trial License button provided. This will complete the license fields
similar to the depiction below.




Once the license key has been recognized, you may click on the Register button to complete trial activation of
the database.
                                                                        Manual Scope and Target Audience

                            Setting up a Lava Database
Note that if you use the full development system installation as described in the previous chapter, this will install
a fully initialized and configured sample database. If, in addition, you activated the sample database during the
install, you may skip this step.

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
Note : If you installed the Qubik Blueprint Build as described in the previous chapter, you m ay set up the
Adm inistrator as described but should skip the actual database creation.

As with all 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 should take no more than a minute.


Start the Lava Administrator

Select the Lava Administrator option from the W indows Start menu - this should be under the Qubik Lava
menu..

The Lava Administrator starts up unlinked to any database, and can be used for several purposes - in this
instance, we will invoke database creation.

Once the Lava Administrator has started successfully, you should see the following interface :
                                                                        Manual Scope and Target Audience

First select the Defaults pane.




Check the entries under the General option.

•        User
         The master user for every Lava database must be system. The password for this user may be changed
         subsequently, and you may also add further users and determine appropriate privilege levels, but the
         system user is mandatory and automatically has full privileges to the entire database.

•        Password
         The initial password for the system user must be manager. You may change this subsequent to
         creation, but the default initial password is fixed.

•        Server
         This must be a correct address for the Lava server. For the initial installation this should be the address
         of the local machine.

•        Satellite server
         Not required at this time. Used only for satellite server configuration.

•        Standby server
         Not required at this time. Used only for standby server configuration.

•        Client Path
         Should be a valid specification for an existing temporary folder. This folder is used as temporary
         storage for all Lava clients.

•        Data Path
         This path must fully specify the location of the Lava database. If you are about to create a new
         database, any valid folder specification is fine. Ensure that the drive selected has sufficient free space
         to accommodate the database you are planning for.

•        Backup Folder
         The backup folder is only required for specialized backups performed from the Query system. You
         should not need to enter this now.
                                                                       Manual Scope and Target Audience

•        Switches
         Switches are special purpose startup options, which you should not require at this time.


Now switch to the Launch pane.




Creating a Lava Database

Note : You do not need to do this if you are installing for the first tim e and wish to use the sam ple database
included with the installation. Skip this step if this is your first installation.

Select the Create Database option. This will create a Lava database at the nominated data path.
After successful creation, you should see the following confirmation :




Possible Creation Problems

There are a few problems that may occur during database creation. In all cases, the following message box will
appear :
                                                                        Manual Scope and Target Audience




Possible problems are :

•        Nominated Data path is not valid
•        Insufficient space on the nominated drive
•        Insufficient privileges to create required folders and files
•        A database exists at the nominated Data path and is currently mounted

In order to correct these problems, you will need to correct the selected Data path.

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.


Activating a new Lava database
In order to use a Lava database in a multi-user environment, you will need to activate (license) the database. In
order to do this, select the Activate option from the Lava Administrator Launch pane. The activation utility will
display the following dialog :
                                                                          Manual Scope and Target Audience

You may either obtain a license from Qubik Digital, or use the Trial License button provided to allow a 30-day
trial period.

The Trial License button will not appear if your database already has a trial license applied (this should not be
the case with a newly created database, but will happen with existing databases).

If you obtain a license from Qubik Digital, enter (paste or type) the license code provided into the boxes
provided. If you copy the entire license (dashes included) the dialog will split the individual segments
automatically. If you choose to type the license in, be sure to pay attention to alpha characters; the key is case
sensitive.

The Register button will only be enabled if a valid license is entered.

Click on the Register button to activate the database.


Restoring a complete backup
Note that if you are intending to restore a backup to the new database, you will need to activate the database
after restore. If your backup is from a database which was already licensed, the Trial License button will not
appear when you start the activation utility.

For details on the backup and restore process, see the chapter on Backup and Restore in this guide.


Mounting the Lava Server
After creation and activation, you may mount the server. For full instructions on mount modes and server
operation, see the section Services in the chapter on the Lava Administrator, as well as the chapter Controlling a
Lava Server
                                                                        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 Administrator Services panel.

Note that before you can mount the Lava Server, you must have successfully created and activated a Primary
Database - see the section Creating a Primary Lava Database for information on this process. Alternatively, the
installation does install a fully configured sample database - in this case, you may mount the server without
further steps being required.

There are two options for running the Lava server. The first is as an executable. This is valid for provisional
testing or ad-hoc interface to a database. The second is to install the server as a service. This also allows for
installing the Lava monitor as a service, and running a monitored server. This is the preferred option for
permanent installations.

If you are running the Lava Server as an executable (without installing the server as a W indows service) it is
controlled directly, as described in Controlling the Lava Server as an Executable below.

If you have installed the Monitor and Server as services, they are controlled as described in the section Services
in the Lava Administrator chapter.


Controlling the Lava Server as an Executable
If you have chosen not to install the Server as a W indows service, the Server is controlled by executing and
exiting the Server directly.

Even if you have installed the Server as a W indows 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, select the Services panel in the Lava Administrator.
                                                                        Manual Scope and Target Audience

Click on the Standalone Server button, as depicted above. This will start and mount the server in executable
mode.

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.


W hen run as an executable, the server will display a dialog allowing easy control.




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 above after a successful mount :

If any other Lava application (The Query system or another instance of the server) is mounted to the selected
database, the server dialog will display the message “Mount error” after a few seconds.


Dismounting an Executable Server

In order to dismount a standalone ava 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 between a few seconds and a minute, depending on database size and server load just prior to
dismount.

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.


Controlling a Monitored Server

For information on controlling a monitored server (both Server and Monitor installed as W indows services) see
the section Services in the chapter Lava Administrator below.
                                                                        Manual Scope and Target Audience

                                   Lava Administrator
The Administrator is the primary interface to the Lava Server. It provides techniques for monitoring the server
status, setting up parameters for several Lava utilities, and controlling important database attributes such as
system parameters, triggers, users, and schemas.


Functionality In Brief
The Administrator provides mechanisms for controlling, monitoring and configuring all important facets of a
Lava database. The options down the left hand side of the Administrator select functional panels, each of which
provides a specific area of functionality. These are described below.




 Status                        Allows monitoring of primary server status, including active monitoring of the
                               dispatcher mechanism. If connected, also provides information on Server
                               memory usage.


 Defaults                      An interface providing for settings for all important Lava applications as well as
                               the Server and Monitor. Settings include database location, server location, user
                               and password settings, backup and restore folders, and log files. These settings
                               are used as defaults when Lava applications or servers are started.


 Launch                        A set of quick-launch buttons for important Lava applications, including
                               database creation, backup and restore, through SQL Query and Blueprint
                               Developer.


 Parameters                    Display and adjustment facilities for a wide range of database operational
                               parameters.

 Triggers                      Provides visibility on all Satellite Servers as well as the Primary Server, as well
                               as the ability to set both triggers and scheduled processes on any of these
                               servers.

 Services                      Control facilities for Server and Monitor services - allows installation as well as
                               starting and stopping services.

 Users                         Full control over database users - create, modify, and adjust privileges and
                               distribution settings.

 Sessions                      Display and control over Primary Server sessions.

 Schemas                       Display of database schemas, tables and table formats as well as control (create,
                               truncate, drop) over these objects.

 Licensing                     Allows display of current licensed features, and monitoring of utilization



The remainder of this chapter details the functionality of the Administrator.
                                                                      Manual Scope and Target Audience

Status
The status panel displays important information on the operating status of the server. There are two operating
modes, which also determine availability of functionality on many of the other panels.


Operating Modes

The Administrator may be run in either of two operating modes. In the initial (startup or default) mode, the
Administrator is not connected to any server. This allows system parameter configuration prior to Server mount,
as well as providing control of Server and Monitor service status.




To connect to the Server, click on the large Connect button at the top left of the Administrator. After connection
to a Server, the Administrator additionally allows control of Server and Database attributes.




Screen captures from the two status modes are shown above. In Startup mode, the Status panel may be used to
                                                                     Manual Scope and Target Audience
display basic operational information on a monitored server. If no monitor has been configured, the Status panel
will display no useful information in startup mode.

W hen connected, server memory status is displayed in a data grid. This may be refreshed when required using
the refresh button provided.


Defaults




The Defaults panel allows configuration of a number of startup and connection parameters for several Lava
applications. Each of the options (General, Backup, ..) allows configuration of separate parameters for a number
of applications.

Note that passwords are encrypted before storage, and are completely secure.


 Option                                  Parameter                          Purpose

 General                                 User, Password

           The General option is         Server
           used for applications
           (SQL Query) as well as        Satellite server
           several utilities
                                         Standby server
           (Activate, License) and
           facilities presented by the   Client path
           Services panel
                                         Data path

                                         Backup folder
                                                         Manual Scope and Target Audience

Option                                  Parameter             Purpose

Backup                                  User, Password

            Parameters for the Lava     Server
            Backup utility
                                        Client path

                                        Data path

                                        Backup folder

                                        Backup log

Restore                                 User, Password

            Parameters for the Lava     Data path
            Restore utility
                                        Backup folder

                                        Backup log

Stream Elements                         User

            Connection parameters       Password
            for the Stream Elements
            interface                   Server

                                        Client path

Blueprint                               User, Password

            Connection parameters       Server
            for the Blueprint
            development                 Client path
            environment

Satellite                               User, password

            Parameters for an           Server
            optional Satellite server
                                        Client path

Standby                                 User, password

            Parameters for an           Server
            optional Standby server
                                        Client path

Apache                                  User, password

            Connection parameters       Server
            for the LavaStream
            Apache module               Client path
                                                                        Manual Scope and Target Audience

Launch
The Launch panel is a utility panel which allows quick access to a number of important Lava applications and
utilities.




Create Database

Allows creation of a blank database. For detailed information on this functionality, see the section Creating the
Primary Lava Database in the above chapter.

The database will be created at the path defined in the General options in the Data Path parameter.

Note that in order to create a database at a given path, the base path for the database must pre-exist (for example,
given the data path H:\Lava\Primary, the folder H:\Lava must pre-exist.

If a database already exists at the nominated path, creation will be disabled if the database is currently mounted
(either through Server or SQL Query in exclusive mode).

Finally, if a creation is actioned at the path of an existing database, the existing database will be completely
destroyed. Be sure to take a backup of the existing database prior to this if the data is to be preserved. Note also
that no connection to the existing database will be attempted prior to overwriting the database - in other words,
regardless of connection parameters (User / Password) the database will be overwritten.


Backup

Actions a backup on an existing database.

For detailed information on Backup and Restore, see the chapter Backup and Restore below.

Parameters from the Backup option in the Defaults panel are used.

Two backup options are possible - if a Server is specified, the backup will be executed in Client mode after
connection to the nominated server. If no server is specified (i.e. the server specification is left blank), the
backup will be executed using Exclusive mount on the database specified in the Data Path parameter. In this
case, no server may currently be mounted to the nominated database.

The backup will be written to the folder nominated in the Backup Folder parameter.
                                                                       Manual Scope and Target Audience
If a file specification is provided in the Backup Log parameter, a comprehensive backup log will be written to
the nominated file. The log file will be created or overwritten with every backup. The folder in which the
backup log is to be written must pre-exist.

For detailed information on operation of the Backup utility, see the chapter Backup and Restore.


Restore

Actions a restore to an existing database.

For detailed information on Backup and Restore, see the chapter Backup and Restore below.

Parameters from the Restore option in the Defaults panel are used.

Restores are unconditionally performed in exclusive mode to the database specified in the Data Path parameter -
no server may be mounted on this database at time of restore.

Backups will be listed from the folder nominated in the Backup Folder parameter.

If a file specification is provided in the Backup Log parameter, a comprehensive restore log will be written to the
nominated file. The log file will be created or overwritten with every restore. The folder in which the restore
log is to be written must pre-exist.

For detailed information on operation of the Restore utility, see the chapter Backup and Restore.


Activate

Newly created databases or databases on which a comprehensive restore has been performed using data from
another server are not activated for server mount. The database may be mounted exclusively using SQL Query,
Backup or Restore before activation, but will not permit Server mount until activated.

The activation utility uses the User / Password and Data Path parameters from the General option in the
Defaults panel. Note that the user and password must be valid and should have Update permission for the
System schema of the database. It is recommended that the system account be used by preference.

For activation, a valid Lava activation code will be required. The installation ID will be displayed by the
activation utility. This ID must be provided to Qubik Digital for provision of a license (confirmation ID) which
will activate the database.


Add License

The Add License utility allows licensing for additional Lava components such as Satellite Servers or Blueprint to
be added to an activated database. Operation of the Licensing utility is identical to the Activation utility above,
but may be performed on a mounted database as a client.

For additional licensing, an appropriate license code must be purchased from Qubik Digital. Note that license
limits apply especially to the smaller activation licenses.


SQL Query

SQL Query is a general-purpose SQL query browser which may be used in either client or exclusive mode.
Parameters from the General option in the Defaults panel are used - these may be overwritten if the Advanced
option is selected from the login dialog.
                                                                      Manual Scope and Target Audience
Details on usage and operation of the SQL Query browser may be found in the chapter entitled Lava Query
System.


Stream Elements

The Stream Elements interface provides a runtime environment for programs written in LavaStream as batch
programs without a user interface. This allows software such as data import, report preparation and other data
centric routines to be executed and monitored. As the LavaStream language is also used for stored functions in
Lava SQL, it is possible to test these functions in an isolated and controlled manner using the Stream Elements
interface.

Details on the LavaStream programming language may be found in the Qubik LavaStream Language
Reference


Blueprint

The Blueprint Development Environment is a comprehensive software development system, providing 3GL and
4GL language interfaces and compilers, a syntax-aware editor, entity relationship diagrammer, project
management facilities, version control, and centralized development storage in a Lava database.

Details for the Blueprint environment can be found in the Qubik Blueprint Operation Guide


Parameters




The parameters panel provides an interface to the database system parameters. The following categories of
parameters are presented amongst others :


 Index parameters                      System settings for limits and trigger values determining behaviour of
                                       the index subsystem. Values should not be adjusted by the user.

 Bulk operation tuning                 Parameters for determining cycle timing during mass update from
                                                                      Manual Scope and Target Audience

                                       client to server. Values should not be adjusted by user.

 Server communication tuning           Port and delay settings for client / server communication. Values
                                       should not be adjusted by user.

 SQL planner cost parameters           Factors and penalties used by the SQL planner expert system to
                                       determine execution plans for multi-table SQL statements. Several of
                                       these values are critical to the correct evaluation of execution plans,
                                       and should not be modified without detailed knowledge of the
                                       operation of the planner expert system.

 Template generation parameters        Parameters used by the Blueprint development system to determine
                                       LavaStream procedures responsible for specific interface and
                                       generation functions. Setting of these parameters is documented in the
                                       Blueprint Operation Guide

 Tree constants                        Settings generated by the system for tree templates used to display
                                       standard user-interface trees (such as the Parameter tree itself). Values
                                       may not be adjusted by the user.



W ith the exception of the Template Generation Parameters, it is not advised that users make adjustments to the
system parameters. Many values are critical for correct system performance or behaviour, and adjusting settings
to inappropriate values may render the system non-functional.
                                                                     Manual Scope and Target Audience

Triggers




The Trigger and Schedule panel provides a means of defining table triggers and scheduled processes.


Scheduled Processes

Processes may be written in LavaStream with an enforced formal parameter set and scheduled on any active
server with the exception of a standby server.


Triggers

Triggers are written in LavaStream with an enforced formal parameter set, and are triggered on update to any
row of the nominated table.
                                                                         Manual Scope and Target Audience

Services
The Services panel allows control of the Lava Server, either in standalone mode or as a monitored service.


Server Modes

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, in standalone mode


         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 and information facilities.

•        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 installations ranging from small to very large. The only option not explicitly
         invoked here is a standby server for server redundancy.


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 are using the installation database,
everything is already set up to run the Lava Server as a standalone executable.
                                                                         Manual Scope and Target Audience




From the services page, in the Server box, select the Standalone Server button. This will start the server using
the options as specified in the General page of the Defaults panel. Most specifically, the Data Path
specification will nominate the database folder - ensure that this points to a valid, activated Lava database.

In standalone mode, the server will display a small status window, as depicted below :




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 W indows 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, need to select the Install Server option from the Services panel.
                                                                          Manual Scope and Target Audience




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 :




This will clearly indicate that the server is currently installed. Note that the server does not need to be re-
installed as a service if you perform an upgrade of the software - the service installation merely points to the
installation folder, and will run whichever revision of the software is currently installed on your server.


Starting the Lava Server when installed as a Service

To start the service, select the Start Server option as depicted below.
                                                                       Manual Scope and Target Audience




Running a Lava Server

W hichever mode you have selected, you should now have a server mounted on the specified database.

If the Microsoft W indows Firewall is activated on your server, directly after the Lava Server is started W indows
will present the following dialog :




                       Windows Security Alert

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.
                                                                        Manual Scope and Target Audience
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 :




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.
                                                                        Manual Scope and Target Audience
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 W indows Firewall is activated on your server, directly after the Lava Server is started W indows
will present the following dialog :




                       Windows Security Alert

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 W indows 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 W indows Service window and it will release the
registry, allowing installation of the service.


Users

Sessions

Schemas
                                                                       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 :

•        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
         W here 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

•        Specific Backup
         W hile comprehensive backups can be performed using the Backup utility (see the chapter Backup and
         Restore), specific backups of single tables or small sets of tables can be performed from within SQL
         query.


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 W indows 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 W indows application at initial encounter is the
requirement to log in (which can be relegated to command-line parameters or defaults in the Administrator) 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. The initial
interface on invocation is the basic connect dialog, depicted below.
                                                                        Manual Scope and Target Audience




To connect to the default server, press enter or click on the large “Enter” button.

If you wish to change any of the default connect settings, you may select the “Advanced” button (>>>) to the
right. This will invoke the advanced connection dialog, depicted below.




To connect to a specific server, change the “Server” field to either an appropriate network server name, or an IP
address. You may also use a URL - in this case, note that only the address portion of the URL should be used
(such as www.lava-sql.com) omitting any protocol specifiers (such as http://)

A valid user / password combination must be entered to successfully connect.

Once all fields have been completed, you may click on the connect button which will result in a Lava Server
connection if all the connect parameters are correct.


Connecting Exclusive

In order to perform certain administrative actions it is necessary to connect exclusively to the database. W here
such an operation must be performed, you must ensure that the Data Path field is set to the correct folder for the
desired database.
                                                                       Manual Scope and Target Audience
To connect exclusively to the nominated database, the database must be unmounted - i.e. no server may be
mounted on the nominated database. Provided this is the case, click on the “Exclusive mount” button to mount
the database.



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.
                                                                        Manual Scope and Target Audience
/ClientPath=S:\Temp


Server address

The server may be specified in one of three ways. The first is through a local network server name, such as
QubkServer. The second is through specification of an IP address, which may be on the local network or
remote, and may reside on the Internet. The third is through use of a conventional Internet URL, using only the
address portion of the URL.

/Server=QubikServer
/Server=127.0.0.1
/Server=www.lava-sql.com


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 W indows 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 :
                                                                        Manual Scope and Target Audience




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.
                                                                       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, it is still 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




 Lava Event Log


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).
                                                                        Manual Scope and Target Audience

                                    Backup and Restore
Backup Procedures
Backup Wizard

In order to execute a backup, first ensure that the settings for backup are completed in the Defaults pane of the
Lava Administrator.

Specifically, you will need to ensure that the Data Path and Backup Folder settings are correctly specified.

Note that backups may be completed either through exclusive mount (the Lava server is dismounted) or in client
mode (as a Lava distributed client to the Lava server).

If you wish to execute the backup in client mode, you will also need to ensure that the Client path and Server
settings are correctly specified.

The backup system for a Lava database is extremely simple. To invoke the backup utility, use the Backup option
from the Launch pane of the Lava Administrator.




In order to direct the backup utility to the correct database, ensure that the Backup settings in the Defaults pane
of the administrator are correctly set. Specifically, the following settings are required :

Backup Folder               :        Must stipulate a valid, existing folder. The drive must contain enough free
                                     space for the intended backup.
Server                      :        If the backup is to be executed in client mode (i.e., backup executed from an
                                     active primary Lava server), the Server setting must specify the machine
                                     name, IP address or URL of a valid, reachable Lava server.
Client Path                 :        If executed in client mode, a valid temporary folder must be specified for
                                     client data. This folder must exist and the drive should have sufficient free
                                     space to store the entire backup.
Data Path                   :        If the backup is to be executed in exclusive mode (i.e., backup to be
                                     executed on a dismounted Lava database) the Data Path must point to the
                                     correct database folder.

If desired, you may automate login by completing the User and Password settings - either or both of these may
be omitted to force the login dialog to request completion of login details.
                                                                      Manual Scope and Target Audience

The backup interface is depicted below :




To select the scope of the backup, flag or unflag schemas you wish to include / exclude from the bacup.

Enter the required name for the backup in the entry field provided. If previous backups exist, you may select
one of the existing backup set names by dropping the list.

Once these selections have been made, click on the Backup button to execute the backup.

The backup will place a set of backup files in the nominated backup folder.


Manual Backup Configuration

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 W indows files, depending on the nature
of the backup. The data portion of each backup file is compressed (and may be encrypted).

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.
                                                                       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
edge of the column, as indicated below. Select the desired schema to back up from the list presented.
                                                                        Manual Scope and Target Audience




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 M anual Backups

To perform a configured 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

Prior to executing a restore, the server must be dismounted.

For information on shutting down the Lava server, see the section entitled Services in the chapter on the Lava
Administrator.


Restore Wizard

The restore system for the Lava database is extremely simple. To invoke the restore utility, use the Restore
option from the Launch pane of the Lava Administrator.




In order to direct the restore utility to the correct database, ensure that the Restore settings in the Defaults pane
of the administrator are correctly set. Specifically, the following settings are required :

Backup Folder               :         Must stipulate the folder in which the required backup is stored.
Data Path                   :         The Data Path must point to the correct database folder to which the backup
                                      set is to be restored.

If desired, you may automate login by completing the User and Password settings - either or both of these may
be omitted to force the login dialog to request completion of login details.

The restore interface is depicted below.
                                                                       Manual Scope and Target Audience




Using the drop lists provided, first select the required backup set by name. The second drop list will provide a
date and time list for available backups. Select the specific backup required.

Once the backup has been selected, click on the Restore button to commence the restore.
Manual Scope and Target Audience
                                                                        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 :




         Data Import from ODBC

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.
                                                                         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
As with most SQL servers, the Qubik Lava server is capable of serving clients in standard client-server mode. In
this mode of operation, the client sends SQL commands to the server, which the server executes on the Lava
Database. If there are results from the command (i.e. if the command was a SQL query) the server transmits the
results of the query back to the client.

The above portion of client-server operation on a Qubik Lava SQL server is identical to that on virtually any
SQL server. The major difference arises where result sets are derived from a SQL query - in other words, if the
SQL query produces a table of results. In this case, differently from other SQL servers, the result set is
presented as an array of data accessible through standard memory array techniques - even for very large result
sets.

In addition, the result set is unconditionally presented as a data table on the client, and will allow SQL queries or
updates to be performed on the result table. This is analogous to performing a create table as select command
on a conventional SQL server, with the exception that the result set is placed on the client - in other words,
subsequent commands executed on the result set are executed directly on the client, resulting in faster operation
and independence from server load.

A further difference between Qubik Lava and other servers is the fact that a Qubik Lava client is unconditionally
a distributed client. This means that, although SQL commands may be executed on the server, if these
commands affect data in tables which are present on the client in distributed form (see Distributed Client below
for details on this mode of operation) these tables will unconditionally be updated after the execution of the SQL
command, allowing the results to be queried either on the server or on the client.


Distributed Client
All Qubik Lava clients are, in fact, distributed clients. This means that the client application runs a complete,
fully functional SQL database, on which one or more schemas may be distributed from the primary Qubik Lava
server.

A distributed table is, as one would expect, a table for which the contents have been copied from the primary
server to the client. The primary server ensures that the content of the local (client copy) of the table are always
up to date, with typically no more than a 10 second delay between the update of any row in the table from any
other client and the update of that row on the local client. Similarly, any update to the table on the local client is
automatically distributed to all other clients connected to the server.


Fully Distributed Tables

The client may nominate any schemas - or any set of tables from a schema - on the server for distribution. The
server will distribute all nominated data to the client, and subsequently ensure that the data is up-to-date at all
times, regardless of any updates performed from any active client.

The implication of the distributed mode of operation is that updates and queries to distributed tables may be
performed on the client directly. This has several benefits :
!       As the query executes locally, no network latency, delays or bandwidth limitations are experienced
!       Any operation is performed independently of load caused by other clients - each client workstation is
        responsible only for local queries and updates, so if other clients are running complex updates or
        reports this load does not cause delays to the local application
!       Updates from remote clients are executed extremely efficiently as a result of database optimization and
        design, so that even if large updates are executed by a remote client the load on the local server is very
        small. Part of the reason for this is the fact that the local update is performed entirely in memory, by a
                                                                         Manual Scope and Target Audience
         lower priority background thread.
!        Similarly, neither complex reports nor updates performed on the local client have any effect on other
         clients connected to the same Qubik Lava server. Hence, application writers have greater freedom in
         structuring and designing client applications without having to take server load into account.
!        As a result of all of the above, the net server load is much lower than with conventional SQL servers. A
         given W indows server, perhaps capable of adequate performance with 50 clients connected to a
         conventional SQL server, will probably perform adequately with 500 clients in a Qubik Lava
         installation due to reduced and optimized server load.
!        Network bandwidth is reduced dramatically as a result of vastly reduced traffic, both due to highly
         optimized data flow where updates are performed, and reduced or eliminated data transfer on execution
         of reports as most of the queries are executed locally on the client with no resulting network traffic at
         all.
!        Data tables on each client are accessed as if the application is mounted exclusively to the central
         database. This allows direct row-level operations such as GetRow and PutRow, as well as - in some
         cases - direct memory array access to table data through indexes, resulting in extremely fast and flexible
         data access
!        W orkgroup operation of applications is automatic. Each client application immediately and
         automatically has access to all data modified by all other clients, in their local database. This allows
         workgroup interactive applications to be written with no extra effort or design on the part of the
         programmer.

In addition to the above, there are many smaller benefits which arise from having - to all intent and purpose -
direct access to the database, which make application design and coding much easier.


Distribution On Demand

As an alternative to fully distributed mode, it is possible to nominate any number of tables for distribution on
demand. In this mode, instead of distributing the entire table content to the client, the server only distributes
data which the client specifically requests. This mode is typically used for very large tables, where distribution
of the entire set of data is prohibitive either in terms of the time taken to transmit the data to the client, or in
terms of the total size of the dataset.

W hen operating a table in on-demand mode, if the client performs any query which would access data not
currently available on the client database, a request is automatically sent to the server to retrieve the requested
data, which then forms part of the distributed data to the client for the table. In this way, any portion of the data
is only requested from the server once - subsequently, that portion of the data together with all previously
distributed data is accessed and manipulated on the client as for a fully distributed data table.


Interruption of Server Connectivity

If, for whatever reason, connectivity to the server is interrupted (either due to network failure or due to the server
failing and being restarted) the client typically continues to operate as if nothing had happened. As the client
database is a complete, fully functional Qubik Lava database, all distributed data tables are available at all times,
regardless of the status of the link to the server.

Obviously, in order for the client to function in complete synchronization with the server, the link must be
established from time to time - especially when committing data or if new on-demand data is requested from the
server. However, unlike most SQL server databases, interruption of the connection to the server is no cause for
the client to fail. The Qubik Lava client will merely attempt periodic reconnection to the server in the
background, and as soon as reconnection is established will perform all pending operations which require
communication with the server.


Primary Server as an Executable
The Qubik Lava server may be run as a standalone executable, typically during initial evaluation. This mode of
                                                                           Manual Scope and Target Audience
operation is fairly restrictive, as no monitoring can be performed and the server is not automatically restarted on
server reboot. It is, however, very simple to set up and allows testing of the Qubik Lava server with the
minimum of effort on the part of the administrator.


Primary Server as a Service
The Qubik Lava server may very easily be installed as a service. Through use of the Lava Control Panel (see
Controlling a Lava Server above) the server can be installed as a service, started and stopped in a matter of
seconds. In addition, the service is set up to start automatically on W indows server reboot, ensuring that the
Qubik Lava server is available at all times.

In order to run the monitor (see below), it is essential to install the server as a service, as this allows the monitor
to start and stop the server remotely as required.

Note that even if the Qubik Lava server is installed as a service, it is still possible to run the server as an
executable for testing purposes.


Server Monitor Service
If the Qubik Lava server is installed as a service, it is possible to install and operate the Qubik Server Monitor.
The monitor, when in operation, opens a mailslot link to the Qubik Lava server and checks operation and status
of the server about once a second.

Should the monitor determine either that the Qubik Lava service has stopped (perhaps due to catastrophic
failure) or that the server is no longer processing requests (which could happen as a result of deadlock, also
known as deadly embrace) the monitor will stop (if required) and restart the Qubik Lava service, restoring the
server to proper functional status.

Note that due to the nature of the Qubik Lava database and the way the server and distributed client connection
is designed and implemented, temporary unavailability of the server has little or no effect on any clients in use at
time of the interruption of service. These clients merely reconnect to the server in the background, typically
without the operator being aware of this happening, and the distributed client continues to operate as if no
interruption had occurred.


Satellite server
The satellite server is a mechanism to solve one or both of the following problems which occur in database
implementations :
!        Several of the client applications are situated at a location where the network bandwidth to the primary
         server is restricted, so that the bandwidth required for connection including primary distribution, update
         processing and associated update distribution exceeds the actual bandwidth available
!        The number of clients requiring connections to the primary server exceed the ability of the primary
         server in terms of processing, memory or both

A satellite server forms a functional extension to the primary server. The satellite server connects to the primary
server, in a similar fashion to a distributed client. Also similarly to a distribute client, one or more schemas are
fully distributed from the primary server. The satellite server, however, also has the ability itself to accept
connections from Qubik Lava clients, in a way which - to the client - mimics the functionality of the primary
server to the point where the client cannot tell the difference between a connection to a satellite server and a
connection to the primary server.

On receiving a request from a client, the satellite server will, as necessary :
!       distribute the associated data to any connected clients and the upstream server
!       request further data from the upstream server
!       answer a query fully without referring to the upstream server
                                                                          Manual Scope and Target Audience

W here the problem relates to restricted bandwidth, placing a satellite server on the other end of the low-
bandwidth link allows the clients to connect to a server on the local network. The initial connect distribution is
performed from the satellite server, eliminating the problems of distributing the data across the low-bandwidth
line. Updates and the data to be distributed in association with these updates are concentrated by the satellite
server, and the minimum amount of data is transmitted across the line to the primary server. Local re-
distribution of updates are performed on the local network.

If the problem relates to the number of connections to the primary server, arranging a group of three or four
satellite servers around the primary server - obviously on separate W indows servers - and configuring the clients
in three or four groups, each to connect to one of the satellite servers. This divides the client load between as
many W indows servers as required, and the primary server load is decreased dramatically as the majority of the
processing load is carried by the satellite servers.

It is possible, if requirements dictate, to chain satellite servers. In cases where a sequence of low bandwidth
links connect a series of branch offices, for example, it is possible to place a satellite server at each branch
office, the satellite servers connected to one another, with only the final satellite in the chain connected to the
primary server.


Standby Server
The standby server is a hot-standby replication server which is continually updated with all information stored in
the Primary Server.

Due to network latency and update cycle times, the Standby Server is typically around 10 seconds behind the
Primary Server in terms of current updates. In other words, if the Primary Server should fail for any reason, in
most cases the last 10 seconds of updates will not have been transferred to the Standby Server and will be lost.
All updates prior to this, though, will have been communicated to the Standby Server.

One further issue to keep in mind is the issue of open transaction frames. As the Standby Server will have to be
dismounted and re-mounted in the role of Primary Server, any open transaction frames will incur a rollback (the
default action when dismounting). As a result, although the data for a particular transaction may be present on
the Standby Server at the time of Primary Server failure, any open transaction frames will be lost.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:2
posted:11/6/2012
language:Unknown
pages:57