SybControl Monitoring & Maintenance Package

SybControl Monitoring and Maintenance Package

Public version 1.0, released 12/01/03

What is it?

This is a set of Perl scripts and modules which watch for problems in Sybase database servers, as well as simplifying some site-wide auditing and setup tasks.

Target Environment

Although the sybcontrol scripts are useful for environments from one to hundreds of Sybase servers and replication servers, they were designed with certain assumptions which were true for the environment they were written and initially deployed in. Those assumptions may not be true on your site. The main odd points about our system were:

Each of our databases had its own replication server. If you can get the licensing for this, it's nice. A seperate replication server process for each database in the system gives you terrific granularity in the event of heavy traffic on one database, preventing the entire system from bogging down. The behaviour of the auditing scripts, when encountering a rep server which is handling more than one warm standby logical connection, is not defined. Monitoring should not be affected, however.
All replicas were full replicas, not partial. We always replicated all the tables in our subscription replicas, even if we didn't need them all. This made it easier to audit - if a table was on one machine's copy of a db but not another, we knew there was a problem.
Read and write logins were seperated by naming convention. Our convention was that, for a database named 'bob', we would create a 'bob_user' and 'bob_read' login. On the master for that database, bob_user would be unlocked, and on the read replicas, the bob_user login would be locked. bob_read would be present and unlocked on all replicas. If you're not interested in enforcing read/write logins, you might want to bother running the reccount.pl auditing script.
All our primary keys were clustered indices. Our tables just happened to perform better that way, for the kind of operations we did. So, we established that as a convention.

There are probably many other things about the environment these scripts were developed in which may not be true in yours. We are interested in your feedback to either render them more universally applicable or at least document their departures from the norm.

Installation

The open-source Mon::Client and DBD::Sybase modules are necessary for out-of-the-box operation, as is a directory named '/opt/sybase/Sybcontrol', writable by the user which will be running these scripts, for temporary files. With the exception of the files in the 'local' directory, these do not have to be run on the actual data server. In our experience, it's easiest to install the Sybcontrol package on the server you run your ID server on, as the ID server is already in a configuration management role to begin with.

You will need to create an interface file entry called 'SCmaster', or change the scripts to point to whatever server you're going to install the SYBCONTROL database on. The SYBCONTROL tables should be created using the schema in sql/sybcontrol.sql. From there, you insert records into the tables in SYBCONTROL indicating which hosts should be monitored. Inserting records into the tables is not yet well documented, but may be apparent upon inspecting the Perl scripts.