User guide
4 Important Concepts
SQL SENTRY COMPONENTS
SQL Sentry consists of the Client (a thin client application), the Monitoring Service (a Windows
service), and a SQL Server Database. The SQL Sentry Database stores event metadata and history
information collected by the SQL Sentry Monitoring Service and the SQL Sentry Client provides a thin
client interface for viewing and managing this information.
One SQL Sentry Monitoring Service is typically required for every 50 to 100 monitored SQL Servers,
Analysis Services connections, SharePoint Servers, Oracle Databases or Windows Task Schedulers.
Multiple Monitoring Services can be installed for scalability, redundancy, or to collect information from
remote sites. Normally a SQL Sentry Client will be installed on each DBA's workstation. All SQL Sentry
Monitoring Services and Clients connect to the same database.
It's important to note that SQL Sentry does not attempt to replace SQL Server Agent, Oracle
Scheduler, Windows Task Scheduler or any other scheduling agents. Instead, SQL Sentry
communicates with these schedulers to ascertain event status, and collect history and performance
information using a lightweight polling architecture. Thus SQL Sentry does not require agents installed
on each monitored server, dramatically reducing associated setup and maintenance overhead of
agent-based systems. SQL Sentry also does not install a database on every monitored SQL Server.
ALERTING AND RESPONSE SYSTEM
As part of its Alerting and Response system, SQL Sentry uses the concept of Conditions and
Actions. Conditions describe the various states of monitored objects in your environment. You
configure Actions to take place when a Condition is met.
All Actions work on the principle of inheritance. This means that if you configure an Action in response
to a Condition being met at the global level (Shared Groups node in the Navigator pane), it will be
automatically passed down to all applicable objects below it. This allows you to define global Actions
for the most common issues across your environment once, and have those passed down to every
monitored server automatically.
You can further refine Actions at each level as needed. This gives you the ability to determine exactly
what happens in response to events occurring in your server environment. Each Connection type
supports multiple Conditions and Actions.
Configuring Actions globally provides a powerful way to significantly reduce the setup and
configuration time required to implement notifications. For example, by enabling the Send Email
Action for the global SQL Server Agent Job: Failure Condition, you will automatically receive email
alerts for any SQL Agent job failures across your enterprise. The only requirement is that the SQL
Server connection and its jobs be "watched" by SQL Sentry. For a more detailed explanation of how
Conditions and Actions work see the Alerting and Response System topic in the SQL Sentry User
Guide.
“WATCHING” CONNECTIONS AND OBJECTS
Throughout this document you'll also see the term "watch" used frequently, in the context of
SQL Sentry Quick Start 5
©2015 SQL Sentry. All Rights Reserved.