and
Administration Guide
Table of Contents
Manual Scope and Target Audience
Installing the Lava Server software suite
Creating the Primary Lava Database
Dismounting an Executable Server
Controlling a Monitored Server
Running the Lava Server as an Executable
Installing the Lava Server as a standalone service
Starting the Lava Server when installed as a Service
Installing the Monitor service
Monitored Lava Server operation
Starting a Monitored Lava Server
The Lava Query System as a Lava Client
Setting Command Line Parameters
Specifying individual tables in a Backup Set
Interruption of Server Connectivity
Primary Server as an Executable
List of IllustrationsLava
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
This PDF document is extensively hyperlinked. In order to derive the best usage from this document, note that the Acrobat PDF reader has a “back” button (just like a browser) located in the toolbar, which looks like this :
After following a hyperlink (any blue underlined text) by left-clicking on the hyperlink with your mouse, clicking the “back” button will return you to the hyperlink just accessed. The “back” button will work through multiple levels of links.
The “back” option can also be found in the mouse right-click pop-up menu, named “Go to Previous View”.
Note that as of Acrobat 6, the “back” option is no longer presented in the pop-up menu, and the toolbar looks slightly different :
|
Also, the toolbar is not displayed by default, and must be activated in the Toolbar options as follows :
|
There is a keyboard shortcut for the Previous View function, which is Alt+Left Arrow
The basic requirement for the Lava SQL Server is a minimum of Windows NT 4 with Service Pack 5 installed. The server will install and run on the following operating systems :
Windows NT 4 (with at least Service Pack 5), 2000 or XP, or Windows Server 2000 or 2003.
The client applications included in the server installation (Lava Query and Lava Mimic) will only run on Windows releases from Windows 2000 onward.
The clients are tested on :
Windows 2000 or XP, Windows Server 2000 or 2003.
The manual is divided into a number of sections, each of which addresses a specific topic.
Describes the procedure for installing the Lava Server software suite. Contains important information on the meaning and interpretation of selections to be made during the installation process.
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.
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.
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.
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).
This section should be read by any prospective power user of a Lava Database. It introduces major features, requirements and constraints of the Lava Database, and explains important concepts which distinguish the Lava Database from other SQL databases. All users of Lava Databases who intend to interact with the database through any of the interface mechanisms should at least read the Key Concepts subsection.
Installing a new Lava Database comprises three major steps.
The first is to install the server software suite. This process is described in this chapter.
The second is to create a new database. This is described in the chapter Setting up a Lava Database.
The third is to configure and start the Lava Server. This is described in the chapter Mounting the Lava Server.
Once these three steps have been performed (which should take no more than 5 minutes in total) you will have a fully functional Lava SQL Server, ready to accept connections.
Installing the Lava Server software suite
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.
|
|
Follow the setup dialogs, completing all required entry fields. The following paragraphs list the important steps during the installation process.
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
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.
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 Windows 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.
|
|
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).
|
|
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.
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.
Once all options and selections have been completed, selecting the Install button will complete the installation - only a few seconds should be required.
You will need a license key to use the new installation. During the installation process, the following dialog will be presented :
|
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.
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 may set up the Administrator 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.
Select the Lava Administrator option from the Windows 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 :
|
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.
• Switches
Switches are special purpose startup options, which you should not require at this time.
Now switch to the Launch pane.
|
Note : You do not need to do this if you are installing for the first time and wish to use the sample 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 :
|
There are a few problems that may occur during database creation. In all cases, the following message box will appear :
|
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 :
|
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.
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
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 Windows 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 Windows service, the Server is controlled by executing and exiting the Server directly.
Even if you have installed the Server as a Windows service, it is still possible to run it as an Executable if you wish to do short tests. Note, however, that the redundancy offered by the Monitor is not available in this mode of execution.
Mounting an Executable Server
To mount an executable Lava Server, select the Services panel in the Lava Administrator.
|
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.
When 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 Windows services) see the section Services in the chapter Lava Administrator below.
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.
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.
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.
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 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.
When connected, server memory status is displayed in a data grid. This may be refreshed when required using the refresh button provided.
|
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 used for applications (SQL Query) as well as several utilities (Activate, License) and facilities presented by the Services panel |
Server |
|
Satellite server |
|
|
Standby server |
|
|
Client path |
|
|
Data path |
|
|
Backup folder |
|
|
Backup |
User, Password |
|
Parameters for the Lava Backup utility |
Server |
|
Client path |
|
|
Data path |
|
|
Backup folder |
|
|
Backup log |
|
|
Restore |
User, Password |
|
Parameters for the Lava Restore utility |
Data path |
|
Backup folder |
|
|
Backup log |
|
|
Stream Elements |
User |
|
Connection parameters for the Stream Elements interface |
Password |
|
Server |
|
|
Client path |
|
|
Blueprint |
User, Password |
|
Connection parameters for the Blueprint development environment |
Server |
|
Client path |
|
|
Satellite |
User, password |
|
Parameters for an optional Satellite server |
Server |
|
Client path |
|
|
Standby |
User, password |
|
Parameters for an optional Standby server |
Server |
|
Client path |
|
|
Apache |
User, password |
|
Connection parameters for the LavaStream Apache module |
Server |
|
Client path |
|
The Launch panel is a utility panel which allows quick access to a number of important Lava applications and utilities.
|
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.
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.
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.
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.
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.
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 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.
Details on usage and operation of the SQL Query browser may be found in the chapter entitled Lava Query System.
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
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
|
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 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. |
With 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.
|
The Trigger and Schedule panel provides a means of defining table triggers and 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 are written in LavaStream with an enforced formal parameter set, and are triggered on update to any row of the nominated table.
The Services panel allows control of the Lava Server, either in standalone mode or as a monitored service.
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.
|
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 Windows server, and if you currently have a Lava Server already running, starting a second Lava Server will also result in mount failure. In this case, you can merely close the second Lava Server, the first will continue running without any effect.
Installing the Lava Server as a standalone service
In order to install the Lava Server as a service, need to select the Install Server option from the Services panel.
|
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.
|
Whichever mode you have selected, you should now have a server mounted on the specified database.
If the Microsoft Windows Firewall is activated on your server, directly after the Lava Server is started Windows will present the following dialog :
|
|
Since the Lava Server accepts connections via TCP/IP, it is necessary to Unblock the server in order for any client to be allowed to connect to the server.
The Lava Monitor is a utility service which ensures uninterrupted server operation. The Monitor continuously checks the server for operability, and performs appropriate control actions (Start or Stop) on the server as required when the server is found to be inoperable. Due to the distributed nature of a Lava database, the Client application always duplicates any information which the server needs with respect to any sessions the client has open, and as a result the Client is able to refresh the information in the Server should a brief interruption in service occur. For this reason, since the Monitor ensures that any interruption in service typically lasts only a minute or so while the server is shut down and restarted, this effectively ensures continuous availability of the server regardless of occasional server restarts.
For this reason, running the Lava Monitor is highly recommended - it consumes only a very small number of resources on the server (CPU usage is almost nil, and total memory usage is typically under 4 Mb).
Lava Monitor options
In the current release of the Lava Server, the Monitor can only be run as a Primary Server monitor. As from release 5.0, the option to run a Standby Server monitor will also be available.
Installing the Monitor service
As for installation of the Lava Server, to install the Lava Monitor as a service you need to invoke the Lava Control Panel. To install the monitor, select the following menu option :
|
If you have not yet installed the Lava Server as a service (which is required for correct operation of the monitor, you will be prompted to install the Server at this point :
|
You should merely select the Install Server service button, and the Lava Server will be installed. If you do not install the Server at this point, the Monitor will not be able to function.
Monitored Lava Server operation
Starting a Monitored Lava Server
To start a Monitored Lava Server, you only need to start the Lava Monitor service. This may be achieved by selecting the following menu option from the Lava Control Panel :
|
Note that if you have not yet installed the monitor service, the Start menu option will be disabled. See the paragraph entitled Lava Monitor installation for information on installing the Monitor service.
As with the service installation menus, once the Monitor has been started the only valid action is to stop the Monitor, and therefore the Start option on the menu is disabled.
Once the Monitor has been started, it will automatically start the Lava Server. Provided that the Primary Database has been correctly created (see the section Creating the Primary Lava Database for information on this process), the Lava Server will mount within a few seconds, and you should see the following windows appear :
|
The upper window of the two is the Monitor, which indicates in its status bar that the primary Lava Server is running and accepting connections.
If the Microsoft Windows Firewall is activated on your server, directly after the Lava Server is started Windows will present the following dialog :
|
|
Since the Lava Server accepts connections via TCP/IP, it is necessary to Unblock the server in order for any client to be allowed to connect to the server.
In order to be able to install the Monitor or Sever as services, you need to have administrative rights on the server. If this is not the case, attempting to install the services will fail and return an error message.
If you do have the required privilege, you may find that the Windows Service window (Start>Settings>Administrative Tools>Services) will hold (lock) the service registry, preventing installation or removal of services. If this is the case, merely close the Windows Service window and it will release the registry, allowing installation of the service.
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
Where specific updates or modifications need to be performed to a Lava Database which are not possible from a given application, the Query system allows these updates to be performed via SQL, while the results can be checked using an SQL query subsequently. Commit or Rollback may be selected depending on the success of the update.
• Testing and developing SQL statements
The interface provides a useful mechanism for the evaluation, optimization and checking of SQL to be used within an application
• Specific Backup
While 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 Windows application - with some additional functionality (notably groupware facilities) and typically at higher speed. The only difference the user may experience between a Lava client and a conventional Windows application at initial encounter is the requirement to log in (which can be relegated to command-line parameters 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
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.
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.
|
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.
In order to perform certain administrative actions it is necessary to connect exclusively to the database. Where such an operation must be performed, you must ensure that the Data Path field is set to the correct folder for the desired database.
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.
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.
|
|
The following parameters are provided :
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
The Client Database Path is the path used to establish the Client database when connecting to a Lava Server. Since the Lava Query system is a fully functional Lava Client, it creates a complete Client Database at connect time, which is established at the path specified.
This parameter is mandatory - it is not possible to perform a connection to a Lava Server unless the path specified is valid, and sufficient space (approximately 3 Mb of free space) exists on the drive specified.
/ClientPath=S:\Temp
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
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
Should your workstation be located in a secure environment, and only you or trusted staff have access to your workstation while your Windows user is logged in, you may set the username and password for your default connection via these command line parameters. In less secure environments, the password may be omitted, requiring this to be entered via the connect dialog.
These parameters are optional, and should not be specified unless your workstation is secure.
/User=system /Password=manager
The Lava Query application has a number of important areas presenting information and allowing command entry. These are depicted below :
|
1 Schema Selection
The Schema drop list presents a list of all schemas present in the database, and allows selection of a specific schema which filters the table list (see 2 below). Note that selecting a schema from this list does not alter the default schema for the connection.
2 Table list
The table list presents a list of all tables in the selected schema (see 1 above). Selecting a table from this list presents a list of columns for the table in the column list (see 3 below).
3 Column list
A list of columns for the table selected in the table list (see 2 above)
4 Command history
The command history list presents a list of recently executed SQL commands. Clicking on this list allows selection of the command, which is placed in the SQL command area for modification or re-invocation.
5 Result grid
The result grid is a datagrid which displays the results of the last SQL command issued (if any).
6 SQL command area
This text area allows entry and modification of SQL commands which may be executed by clicking on the SQL command button just above the area.
Each of the areas may be re-sized by clicking on the resizer between any two areas and dragging with the mouse.
The Lava Query system may be disconnected from a given database either by connecting to another database server, or by closing the application. In both cases the Client database utilized during the connection is released, and the space is free for re-use.
All regular administrative tasks required on a Lava Database may be achieved through use of the Lava Query system. For an introduction to the Lava Query system, see the chapter Lava Query System.
Under most circumstances, a Lava Database needs little or no administration - with the exception, of course, of regular backups. Generally, the database does not need monitoring because of space constraints - provided the drive housing the database has sufficient free space, the database will automatically expand to provide for data requirements.
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.
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.
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.
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.
 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).
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.
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.
The Lava Query System provides a backup interface which allows backups to be made from any workstation which can connect to the Lava Server. Speed of backup will depend on the bandwidth to the server and the amount of data to be backed up.
The resulting backup set for a schema is written to disk as one or more Windows files, depending on the nature of the backup. The data portion of each backup file is compressed (and may be encrypted).
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.
|
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).
A backup set consists of only one schema. If, for example, you wish to backup the data for a specific application, the tables for the schema will typically be contained in one schema, and in this case a backup set may be used.
To configure a backup set, first click on the Backup Set row in the tree. The row will highlight, and a create icon will appear next to the row. Clicking on this icon will create a blank backup set entry, as follows.
|
Enter a description for the backup set by clicking in the description column. Select a schema for the backup set by first clicking in the column for the schema, then by clicking on the lookup button placed at the right hand edge of the column, as indicated below. Select the desired schema to back up from the list presented.
|
For a complete schema backup, this is all that needs to be specified. If you do not wish to specify individual tables, skip the next paragraph and continue to the paragraph on performing backups.
Specifying individual tables in a Backup Set
Should you wish to backup only one or more specific tables from a schema, omitting all other tables, you may do this by first expanding the row for the backup set (click on the + icon to the left of the row), then clicking on the row titled “Backup Objects”. A create icon will appear to the left of the Backup Objects row, which allows creation of table entries as follows :
|
A specific table may be selected by clicking in the column labelled “Object”, then clicking on the lookup button to the right of the column.
|
The column may be widened (as in the above example) by clicking on the column divider and dragging to the right, which will allow more visibility on the table names which are presented in Schema.Table format.
More tables may be added to the backup set by clicking on the create button to the left of the Backup Objects row label.
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.
|
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.
|
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).
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.
|
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.
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.
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.
|
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.
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.
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.
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 :
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.
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.
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.
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 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 Windows 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
● Workgroup 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.
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.
When 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 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.
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 Windows 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.
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.
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
Where 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 Windows 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 Windows 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.
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.
