OVERVIEW
--------

DBMonitor Version 2.2 is a small-footprint program, designed primarily for monitoring connections with the databases.  

Every organization supporting several databases has a staff of people responsible for these databases being up and running at least during normal work hours.  The typical environment has a few instances of databases running on several different servers.  Some of them are production type servers and must be watched closely, some may be R&D type that may go down more often because of their nature.  Unfortunately, the typical environment usually doesn't have enough staff to be "on top" of every problem.  Usually if a database goes down (or if a database is OK, but there is another problem that causes users to loose connection) it takes some time for public outcry to reach an overworked DBA. This in not best way to maintain good relations with user community.

There are several tools on the market that allow connection to system Logs etc. to investigate what went wrong and so on.  Usually, though, these tools are complicated enough to require careful installation, sysadmin privileges to install, they are very specialized for each Database server and typically run against one server at a time.  They are also very expensive. 
DBMonitor uses a different approach to make sure your Databases are up and running.
DBMonitor is intended for DBAs, Sysadmins and Managers primarily as alarm.  It will try to connect to each of your databases every so often, and if connection fails, it will send E-mail or NT messages to appropriate people alerting of the problem.  It leaves investigation of the particular occurrence up to whoever is supposed to do that, but it will make sure appropriate personnel will be notified immediately.  So, if DBMonitor is set to check connection with Database every 15 minutes, in the worst case scenario the DBA will be notified 15 minutes after the fact.  If you can't afford 15 minutes - set DBMonitor check the connection at shorter intervals.
DBMonitor is very easy to set up, requires minimum technical knowledge and can monitor any number of databases (only two in a trial version) from different vendors.  You can even use DBMonitor to track the length of your daily/weekly maintenance down-times: Your will get a message stating that the database was not available and when maintenance is over - another message that your database is up and running again.
With DBMonitor you can keep a log of all its connections.  This will provide you statistica and/or proof of the availability of databases.

FUTURE Improvements.
--------------------
Subsequent versions of DBMonitor will allow the user to run certain SQL scripts against a database (such as "check the number of users online") every time it successfully connects to the database, and/or run a batch file executing some DOS based tool, such as PING command to trace TCP/IP connection.
We are committed to providing you with a simple tool to ensure that your databases are being constantly watched so you can get some sleep.

SETUP PARAMETERS
----------------

All setup parameters are stored in an INI file.
Installation process creates a shortcut to DBMonitor that points to dbmonitor.ini file in the same directory you are installing software.  

If you want to create your own INI file you are welcome.  Just make sure in your shortcut you are pointing to the correct location.

The INI file consists of sections.

Section [DATABASES] lists the databases you want to monitor.
Version 2.2 of DBMonitor expects only one parameter in this section: 'databasesections'.  The syntax is
[DATABASES]
databasesections=database1,database2,database3, . . . 

It simply lists section names of the database configuration files in the same INI file.

PLEASE NOTE, THAT 30-DAY FREE TRIAL VERSION OF THE SYSTEM WILL ONLY USE TWO DATABASE NAMES.  THE REGISTERED VERSION CAN SERVICE AN UNLIMITED NUMBER OF DATABASES.

The rest of your INI file contains similar sections for every database. The name of each section should be exactly as mentioned in 'databasesections' parameter.

DBMS parameter:
---------------

It defines what kind of database engine you are running:

DBMS Examples :

[database1]
dbms = o73 Oracle 7.3

[database2]
dbms = or8  Oracle 8

[database3]
dbms = MSS (Msoft) SQL Server 6.0

[database4]
dbms = SYC Sybase System 11

[database5]
dbms = IN5 Ingress

[database6]
dbms = ODBC



SERVERNAME parameter:
---------------------

It defines the name of the specific server name the database resides on (or for Oracle - TNS name):

Servername examples :


[database1]
dbms = o73 Oracle V7.3
servername = @ORCL

[database2]
dbms = or8 Oracle V8.0
servername = ORCL

[database3]
dbms = MSS (Msoft) SQL Server 6.0
servername = 122.222.221.1

[database4]
dbms = SYC Sybase System 11
servername = 121.212.212.2




DATABASE parameter:
-------------------

It defines the name of the specific database to connect to (if it was not specified in Servername, as is the case for Oracle):

Database examples :

[database1]
dbms = o73 Oracle V7.3
servername = @ORCL
database = 

[database2]
dbms = or8 Oracle V8.0
servername = ORCL
database = 

[database3]
dbms = MSS (Msoft) SQL Server 6.0
servername = 122.222.221.1
database = pubs

[database4]
dbms = SYC Sybase System 11
servername = 121.212.212.2
database = pubs


DBPARM parameter:
-----------------

It defines the database specific information necessary for successful connection.  Usually it is used for ODBC type of connections. 

This concludes the explanation of parameters, related to database connection.



The following describes several parameters that can be used to customize the program's behavior:


TITLE parameter
---------------

It defines the title of the sheet on the screen (short name of your database/server) - since you may have several sheets open watching different databases you may want to give them distinct names (they don't have to correspond to database names, but it may be a good idea to use a short name for the corresponding database used in your environment). 

Example:

[database1]
. . . 
title = Sales (Production)


TIMER parameter
---------------
It is the frequency (in minutes) with which the connection is checked.

Example:

[database3]
. . .
timer = 5


LOG parameter
-------------

This parameter specifies whether or not you want to log your connections to keep a hardcopy file.  If specified 'yes' log_file parameter also needs to be specified.  If specified 'No', the system will only show results on the screen.

Example:

[database41]
log = yes


LOG_FILE parameter
------------------

This parameter specifies the name of your log file.  It is recommended that you keep a database log for each database separately.

Example:

[database41]
log_file = c:\dbmonitor\log_sales_prod.txt


SENDMAIL parameter
------------------

This parameter specifies whether you want to send e-mail notification when a connection attempt fails or when connection is reestablished.  Setting it to 'Yes' requires the computer the program is running on to have MAPI compliant e-mail (such as Microsoft Mail) and have it running in the background all the time.   Usually it is not a problem during the day on most computers, but there are situations where it may not be the case - for example if you want to leave the program running overnight and don't want your e-mail program running, or if you are running DBMonitor on a server that doesn't have e-mail capabilities for security reasons.

Example:

[database_test]
sendmail = yes



DOWN_SUBJECT parameter
----------------------

This parameter specifies what will appear in a SUBJECT field of an e-mail message in case the connection failed.

Example:

[database_test]
sendmail = yes
down_subject = Connection With Sales Prod database failed


DOWN_MESSAGE parameter
----------------------

This parameter specifies the body of the E-mail that will be sent in case the connection failed.

Prior to sending the message the text will be scanned and certain parameters substituted with the actual values. The parameters are: #servername#, #database#, #time#, #errcode# and #errormessage#.

Example:

[database_test]
sendmail = yes
down_subject = Connection With Sales Prod database failed
down_message = Connection to the database #servername# #database# failed at approximately #time# with Error Code #errcode# and errormessage: #errormessage#


DOWN_TOx_NAME and DOWN_TOx_ADDRESS parameters
---------------------------------------------

These parameters specify the TO: recipient of an E-mail message that will be sent in case the connection failed. Every person must have separate DOWN_TOx_NAME and DOWN_TOx_ADDRESS parameters.  The format for DOWN_TOx_NAME can be relatively free.  A lot of organizations prefer format "Last_name, First_name".  The format for the e-mail address must follow the rules of your E-mail package.  The numbers for DOWN_TOx_NAME and DOWN_Tox_ADDRESS must be consecutive, i.e. DOWN_TO1_NAME, DOWN_TO2_NAME, . . ..  The first break in sequence will stop filling the TO: list.

Example:

[database_test]
sendmail = yes
down_subject = Connection With Sales Prod database failed
down_message = Connection to the database #servername# #database# failed at approximately #time# with Error Code #errcode# and errormessage: #errormessage#
down_to1_name = Scott, James
down_to1_address = smtp:Scottj@aaa.com
down_to2_name = Wilson, Jessie
down_to2_address = smtp:wilson@aaa.com
down_to4_name = White, Jack 	<- will not get the message (there is a break in a sequence - missing down_to3) 
down_to4_address = smtp:whitej@aaa.com


DOWN_CCx_NAME and DOWN_CCx_ADDRESS parameters
---------------------------------------------

These parameters specify the CC: recipients of an E-mail message that will be sent in case the connection failed. Every person must have separate DOWN_CCx_NAME and DOWN_CCx_ADDRESS parameters.  The format for DOWN_CCx_NAME can be relatively free.  A lot of organizations prefer format "Last_name, First_name".  The format for the e-mail address must follow the rules of your E-mail package.  The numbers for DOWN_CCx_NAME and DOWN_CCx_ADDRESS must be consecutive, i.e. DOWN_CC1_NAME, DOWN_CC2_NAME, . . .. ..  The first break in sequence will stop filling the CC: list.

Example:

[database_test]
sendmail = yes
down_subject = Connection With Sales Prod database failed
down_message = Connection to the database #servername# #database# failed at approximately #time# with Error Code #errcode# and errormessage: #errormessage#
down_to1_name = Scott, James
down_to1_address = smtp:Scottj@aaa.com
down_to2_name = Wilson, Jessie
down_to2_address = smtp:wilson@aaa.com
down_cc1_name = Doe, John
down_cc1_address = smtp:doej@aaa.com
down_cc3_name = White, Jack 	<- will not get the message (there is a break in a sequence - missing down_cc2) 
down_cc3_address = smtp:whitej@aaa.com


UP_SUBJECT parameter
--------------------

This parameter specifies what will appear in the SUBJECT field of an e-mail message when the connection is restored.

Example:

[database_test]
sendmail = yes
up_subject = Connection With Sales Prod database has been restored


UP_MESSAGE parameter
--------------------

This parameter specifies the body of the E-mail that will be sent in case the connection was restored.

Prior to sending the message the text will be scanned and certain parameters substituted with the actual values. The parameters are: #servername#, #database#, #time#, #errcode# and #errormessage#.

Example:

[database_test]
sendmail = yes
up_subject = Connection With Sales Prod database has been restored
up_message = Connection to the database #servername# #database# was restored at approximately #time# 

UP_TOx_NAME and UP_TOx_ADDRESS parameters
------------------------------------------

These parameters specify the TO: recipient of an E-mail message that will be sent in case the connection is restored. Every person must have separate UP_TOx_NAME and UP_TOx_ADDRESS parameters.  The format for UP_TOx_NAME can be relatively free.  A lot of organizations prefer format "Last_name, First_name".  The format for the e-mail address must follow the rules of your E-mail package.  The numbers for UP_TOx_NAME and UP_Tox_ADDRESS must be consecutive, i.e. UP_TO1_NAME, UP_TO2_NAME, . . .. ..  The first break in sequence will stop filling the TO: list.

Example:

[database_test]
sendmail = yes
up_subject = Connection With Sales Prod database has been restored
up_message = Connection to the database #servername# #database# was restored at approximately #time#
up_to1_name = Scott, James
up_to1_address = smtp:Scottj@aaa.com
up_to2_name = Wilson, Jessie
up_to2_address = smtp:wilson@aaa.com
up_to4_name = White, Jack 	<- will not get the message (there is a break in a sequence - missing up_to3) 
up_to4_address = smtp:whitej@aaa.com


UP_CCx_NAME and UP_CCx_ADDRESS parameters
---------------------------------------------

These parameters specify the CC: recipients of an E-mail message that will be sent in case the connection is restored. Every person must have separate UP_CCx_NAME and UP_CCx_ADDRESS parameters.  The format for UP_CCx_NAME can be relatively free.  A lot of organizations prefer format "Last_name, First_name".  The format for the e-mail address must follow the rules of your E-mail package.  The numbers for UP_CCx_NAME and UP_CCx_ADDRESS must be consecutive, i.e. UP_CC1_NAME, UP_CC2_NAME, . . .. ..  The first break in sequence will stop filling the CC: list.

Example:

[database_test]
sendmail = yes
up_subject = Connection With Sales Prod database has been restored
up_message = Connection to the database #servername# #database# was restored at approximately #time#up_to1_name = Scott, James
up_to1_address = smtp:Scottj@aaa.com
up_to2_name = Wilson, Jessie
up_to2_address = smtp:wilson@aaa.com
up_cc1_name = Doe, John
up_cc1_address = smtp:doej@aaa.com
up_cc3_name = White, Jack 	<- will not get the message (there is a break in a sequence - missing up_cc3) 
up_cc4_address = smtp:whitej@aaa.com



SENDNTMESSAGE parameter
-----------------------

This parameter specifies whether you want to send NT message notifications using NET SEND command when connection attempt fails or connection is reestablished.  Setting it to 'Yes' requires the computer the program is running on to be WINDOWS NT machine. 
(not available in a TRIAL version)

Example:

[decision_support_database]
sendntmessage = yes


DOWN_NTMESSAGE parameter
------------------------

This parameter specifies the text of a message sent via NET USE command.
Prior to sending the message the text will be scanned and certain parameters substituted with the actual values. The parameters are: #servername#, #database#, #time#, #errcode# and #errormessage#.  The text can be the same as DOWN_MESSAGE parameter but probably will be shorter.

Example

[decision_support_database]
sendntmessage = yes
down_ntmessage = Connection #servername# #database# failed: Error Code #errcode#

DOWN_COMPx_NAME parameter
-------------------------

These parameters specify the recipient computers of the NT message that will be sent in case the connection failed. Every computer must have separate DOWN_COMPx_NAME parameter.  The value for DOWN_COMPx_NAME can be taken from "NETWORK Neighborhood"- identification .  The numbers for DOWN_COMPx_NAME must be consecutive, i.e. DOWN_COMP1_NAME, DOWN_COMP2_NAME, . . ..  The first break in sequence will stop sending messages.


Example:

[decision_support_database]
sendntmessage = yes
down_ntmessage = Connection #servername# #database# failed: Error Code #errcode#
down_comp1_name = aaacomp4
down_comp3_name = aaacomp7	<- will not get the message 



UP_NTMESSAGE parameter
----------------------

This parameter specifies the text of a message sent via NET USE command.
Before sending the message the text will be scanned and certain parameters substituted with the actual values. The parameters are: #servername#, #database#, #time#, #errcode# and #errormessage#.  The text can be the same as UP_MESSAGE parameter but probably will be shorter.

Example

[decision_support_database]
sendntmessage = yes
up_ntmessage = Connection #servername# #database# was reestablished


UP_COMPx_NAME parameter
-----------------------

These parameters specify the recipient computers of the NT message that will be sent in case the connection is restored. Every computer must have separate UP_COMPx_NAME parameter.  The value for UP_COMPx_NAME can be taken from "NETWORK Neighborhood"- identification.  The numbers for UP_COMPx_NAME must be consecutive, i.e. UP_COMP1_NAME, UP_COMP2_NAME, . . ..  The first break in sequence will stop sending messages.


Example:

[decision_support_database]
sendntmessage = yes
up_ntmessage = Connection #servername# #database# was restored
up_comp1_name = aaacomp4
up_comp3_name = aaacomp7	<- will not get the message



