The Monitor Options page lets you set the default Alerts criteria as well as the Alerts criteria for individual target databases.
It also allows you to force the default Alerts criteria onto all target databases, and to manage multiple Monitor sessions (define, start, stop and delete)
using a tab-delimited file of connection strings.
The title
shows [Default Settings] or the name of the DSN or Connection
String of the target database
to which various options apply.
The New Menu link
opens the Foxhound Menu page in a new browser window or tab.
The Foxhound Options link
opens the Foxhound Options page in a new browser window or tab, where
you can fill in the email server settings for sending Alert emails.
The
button is a context-sensitive link to this Help topic.
This button appears in many locations, each of them a link to a different Help topic in this frame.
Tip:
To hide the Help for every new page, see the Show Help section on the Foxhound Options page.
The About link
opens the About Foxhound page in a new browser window or tab.
This section lets you quickly (and temporarily) turn off certain features without changing (or affecting)
the dozens of other settings that otherwise control how those features work.
The Enable Emails checkbox lets you turn off the Alert email facility for all
target databases being monitored by Foxhound.
This checkbox does not change any other email settings, but it does
override their effect when you uncheck this checkbox.
When you check this checkbox again, all the other email settings take effect again.
The Enable Schedules checkbox lets you turn off all the Schedule facilities
for all target databases being monitored by Foxhound.
This checkbox does not change any other schedule settings, but it does
override their effect when you uncheck this checkbox.
When you check this checkbox again, all the other schedule settings take effect again.
The Enable AutoDrop checkbox lets you turn off the AutoDrop facility for
all target databases being monitored by Foxhound.
This checkbox does not change any other AutoDrop settings, but it does
override their effect when you uncheck this checkbox.
When you check this checkbox again, all the other AutoDrop settings take effect again.
You must click if you want your changes saved.
Any one the Save buttons will save all the changes you have made anywhere on this page.
Performance Tip: This section makes it easier to manage the Monitor Options
for dozens of target databases.
Here's another tip: If you're new to Foxhound, get familiar using the other sections
for one or two target databases before using this section to manage more databases.
The Connection Strings file: field lets you provide the file specification
for a text file containing connection strings for multiple target databases.
The file contains one line per target database, with each line terminated by a
carriage return - line feed pair ('\x0d\x0a'). Each line contains two fields,
separated by a single tab character ('\x09'). The first field contains a unique name
for the connection string, and the second is the connection string itself. Here is
and example:
The button will save all the changes you have made
anywhere on this page, including the Connection Strings file.
The Connection Strings file is used when you press each of the following
four buttons. You can create different files for different purposes; e.g.,
for starting and stopping a large number of Monitor sessions in smaller batches.
Note: If you enter a new value in the Connection Strings file field, and then press one of the
other buttons Create Connection Strings, etc., the new Connection Strings file value will
be saved in the Foxhound database even though you didn't press Save. In this case, only that
value will be saved, not any of the changes you might have made elsewhere on this page.
The button
uses the data in the Connection Strings file to create or replace
Connection Strings in the Foxhound database.
After pressing this button, the individual connection strings will be
visible in the String tab of the Foxhound Menu page. However, the target databases won't be
visible in the Monitor tab of the Foxhound Menu page unless the connection strings had previously
existed and monitoring had been started at some point in the past.
The button
reads the connection string names from the Connections Strings file and
starts a Monitor session for each corresponding target database if
that session is not already running or in the process of starting.
After pressing this button, the target databases will be
visible in the Monitor tab of the Foxhound Menu page.
The button
reads the connection string names from the Connections Strings file and
stops the Monitor session for each corresponding target database
if it is running or cancels that session if it is in the process of starting.
After pressing this button, the target databases will still be
visible in the Monitor tab of the Foxhound Menu page.
The button
reads the connection string names from the Connections Strings file and
deletes the Monitor session for each corresponding target database if
that session is not already running or in the process of starting.
After pressing this button, the target databases will no longer be
visible in the Monitor tab of the Foxhound Menu page. However, the
connection strings will still be visible in the String tab of the Foxhound Menu page.
The buttons in this section let you manipulate entire sets of Monitor Options in different ways.
Performance Tip: Like section 2. Manage Multiple Monitor Sessions,
this section makes it easier to manage the Monitor Options for multiple target databases.
...and again: If you're new to Foxhound, get familiar using the other sections
for one or two target databases before using this section to manage more databases.
The
lets you pick which set of Monitor Options to work on.
Choose [Default Settings] to work on the settings that will be used when you
start monitoring a new target database.
Choose one of the other entries in the drop-down list to work on the options for
that target database.
The choice you make affects this section (Save and Restore Monitor Options) by
enabling and disabling the following buttons:
The button does two things:
First, it works just like a button:
it saves all the values on this page for use with the current target database.
Second, it saves the same values as the [Default Settings].
The button does two things:
First, it replaces all the values on this page with the [Default Settings].
Second, it works just like a button:
it saves all the values on this page as the options set used for the current target database.
The button does two things:
First, it replaces all the values on this page with the original Foxhound "Factory Settings"
that were in effect when Foxhound was first installed.
Second, it works just like a button:
it saves all the values on this page as the [Default Settings],
or as the options set used for the current target database,
depending on which set of options is currently displayed.
The button does two things:
First, it replaces most of the values on this page with extremely aggressive settings.
Second, it works just like a button:
it saves all the values on this page as the [Default Settings],
or as the options set used for the current target database,
depending on which set of options is currently displayed.
CAUTION: These settings are primarily intended for demonstrating how various Foxhound features work.
The button does two things:
First, it works just like a button:
it saves all the values on this page as the [Default Settings].
Second, it saves all the values on this page as the current settings
for each and every target database.
CAUTION: This operation may take some time. It also affects every target database, and there is no "undo" feature.
The Enforce the Sample Schedule checkbox lets you enable the automated Sample Schedule feature for this target database, which
in turn lets you turn sampling off and on at different times of the day.
While a Sample Schedule is in effect for a particular target database, Foxhound does not allow sampling to be manually
started or stopped via the "Start Sampling" or "Stop Sampling" buttons on the Monitor or Foxhound Menu pages.
Instead, a link to the Monitor Options page is displayed: "...Sample Schedule in effect" on those pages.
Each Sample Schedule consists of 7 strings of 96 characters...
AM PM Y,y for yes, P,p for ping, other for no
12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11
Mon YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYyYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
Tue YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYyYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
Wed ...............................................^................................................
Thu YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYyYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
Fri YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYyYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
Sat YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYyYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
Sun YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYyYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
Here's how it works:
Each character represents one 15-minute period, from 12:00 midnight to 12:14:59.999 AM, 12:15 AM
to 12:29:59.999 AM, and so on, 24 hours a day, 7 days a week.
Type "Y" or "y" for "Yes, full sampling is enabled for this 15-minute period".
Type "P" or "p" to "Perform ping-only sampling during this 15-minute period".
Ping-only sampling uses a custom Foxhound "ping" process that tests separate connections
to the target database without gathering any other sample data.
The primary purpose of ping-only sampling is to check for Alert #1 Database unavailable
without storing a lot of data in the Foxhound database.
For example, ping-only sampling might be scheduled during the overnight hours
when a large connection pool is mostly idle, or
when a heavy load is expected and nobody cares much about performance.
When ping-only sampling begins, all active alerts (except Alert #1 Database unavailable) are cancelled
because Foxhound is no longer gathering the information required the check the alert criteria.
Anything else means "No, all sampling is stopped for this 15-minute period".
Foxhound will change the "anything else" to "." or "^" when you click on Save.
Foxhound displays "^" or the lower-case "y" or "p" to show you which column includes the current
clock-on-the-wall time... but be careful, the display isn't updated automatically.
If you type too many characters in one day, Foxhound will chop off the extra characters on the right.
If you don't fill all the characters in one day, Foxhound will pad the day to the right
with "." or "^" characters.
The button changes the day to all "Y" and "y" characters.
The button changes the day to all "." and "^" characters.
The button shifts all the characters to the left by one
position, filling the right-most position with "." or "^"; in other words, it shifts but it doesn't wrap.
The button shifts all the characters to the right by
one position, filling the left-most position with "." or "^"; in other words, it shifts but it doesn't wrap.
The button sets all the characters from 9:00 AM to 4:45 PM
to "Y" or "y", and sets the rest to "." or "^".
The button sets all the characters from 5:00 AM to 8:45 PM
to "Y" or "y", and sets the rest to "." or "^".
You can also copy-and-paste into each day's string of characters.
You must click if you want your changes saved.
Any one the Save buttons will save all the changes you have made anywhere on this page.
The Enforce the Connection Sample Schedule lets you enable the automated Connection Sample Schedule feature for this target database, which
in turn lets you turn the collection of connection-level sample data off and on at different times of the day.
The Connection Sample Schedule has no effect for periods where the Sample Schedule has turned sampling
off, or if sampling has been manually stopped.
The Connection Sample Schedule has no effect when the Foxhound Options - Connection Sample Threshold has
suppressed the collection of connection-level data because the threshold connection count is exceeded.
Each Connection Sample Schedule consists of 7 strings of 96 characters...
Each character represents one 15-minute period, from 12:00 midnight to 12:14:59.999 AM, 12:15 AM to 12:29:59.999 AM, and so on, 24 hours a day, 7 days a week.
You type "Y" or "y" for "yes, connection-level sample data will be recorded for this 15-minute period".
Anything else means "no, connection-level sample data will not be recorded for this 15-minute period".
Foxhound will change the "anything else" to "." or "^" when you click on Save.
Foxhound displays "^" and lower-case "y" to show you which column includes the current clock-on-the-wall time... but be careful, the display isn't updated automatically.
If you type too many characters in one day, Foxhound will chop off the extra characters on the right.
If you don't fill all the characters in one day, Foxhound will pad the day to the right with "." or "^" characters.
The button changes the day to all "Y" and "y" characters.
The button changes the day to all "." and "^" characters.
The button shifts all the characters to the left by one position, filling the right-most position with "." or "^"; in other words, it shifts but it doesn't wrap.
The button shifts all the characters to the right by one position, filling the left-most position with "." or "^"; in other words, it shifts but it doesn't wrap.
The button sets all the characters from 9:00 AM to 4:45 PM to "Y" or "y", and sets the rest to "." or "^".
The button sets all the characters from 5:00 AM to 8:45 PM to "Y" or "y", and sets the rest to "." or "^".
You can also copy-and-paste into each day's string of characters.
You must click if you want your changes saved.
Any one the Save buttons will save all the changes you have made anywhere on this page.
The Use HTML in all emails: checkbox specifies whether or not you want Foxhound
to include HTML-formatted text in Alert and AutoDrop Notice emails.
The Host[:port] for URLs in all emails: field may be used to specify where the Foxhound web server is
located relative to the computer receiving Alert and AutoDrop Notice emails, so that HTML links pointing to Foxhound History
pages from inside the emails can find the right web pages.
The default is localhost which works if the emails are being received on the same computer
that's running Foxhound.
If you start Foxhound on some port other than 80, you can specify a value like localhost:12345.
If Foxhound is running on a different computer you'll have to change localhost to that computer's
domain name or IP address; e.g., xyz.com:12345.
Note: The two fields above apply to both Alert and AutoDrop Notice emails.
The Send Alert emails: checkbox specifies whether or not
you want Alert, All Clear and Cancelled emails to be sent.
Use the Email address(es) for Alerts: field to specify one or more email addresses,
separated by semicolons, that will receive Alert, All Clear and Cancelled emails if they are sent.
Tip: If an Alert email doesn't look right in your browser it may be the fault
of the email service (e.g., Gmail) rather than Foxhound or your browser.
For example, as of March 2016 Alert emails containing formatted HTML showing recent Foxhound
samples would appear misaligned when sent via Gmail but looked OK when sent via Ymail.
The results were the same when viewed in Chrome and Internet Explorer. The problem was caused
by bogus HTML table-formatting tags inserted by Gmail.
The button may be used to check that
the Alert email settings are correct.
The Test result: field will display OK if the test Alert email was sent ok, or
an error message if there was a problem.
You should also check that the
email was received at the other end; just because a message was sent doesn't mean
it will actually arrive.
Here's a list of return codes:
0 Success
1 An invalid parameter was supplied
2 Out of memory
3 xp_startmail or xp_startsmtp was not called
4 Bad host name, or no internet connection
5 Connect error
6 Secure connection error
7 MAPI functions are not available
100 Socket error.
Antivirus software may have blocked the outbound connection to the SMTP server.
Check the "SMTP Server:" field.
101 Socket timeout.
102 Unable to resolve the SMTP server hostname.
103 Unable to connect to the SMTP server.
104 Server error; response not understood.
Check the "SMTP Server:" field.
105 A TLS error occurred.
Check the "SMTP Authorization User Name:", "SMTP Authorization Password:" and
"SMTP Certificate Filespec:" fields.
421 Domain service not available, closing transmission channel.
450 Requested mail action not taken: mailbox unavailable.
451 Requested action not taken: local error in processing. Message may have
been rejected as spam.
452 Requested action not taken: insufficient system storage.
500 Syntax error, command unrecognized. (This may include errors such as
a command that is too long).
501 Syntax error in parameters or arguments.
502 Command not implemented.
503 Bad sequence of commands.
504 Command parameter not implemented.
511 Bad email address.
550 Requested action not taken: mailbox unavailable. For example, the mailbox is
not found, there is no access, or no relay is allowed.
551 User not local; please try forward-path.
552 Request mail action aborted: exceeded storage allocation.
553 Requested action not taken: mailbox name not allowed. For example, the
mailbox syntax is incorrect.
554 Transaction failed.
The message may have been rejected as spam.
The Send AutoDrop Notice emails: checkbox specifies whether or not
you want AutoDrop Notice emails to be sent.
Use the Email address(es) for AutoDrop Notices: field to specify one or more email addresses,
separated by semicolons, that will receive AutoDrop Notice emails if they are sent.
The - or - Same address(es) as for Alerts: checkbox specifies whether or not
you want to use the same addresses for AutoDrop Notice emails as are used for Alert emails.
If you check this box, you will notice that any changes you make to Email address(es) for Alerts:
are copied to Email address(es) for AutoDrop Notices:
The button may be used to check that
the AutoDrop Notice email settings are correct.
The Test result: field will display OK if the test AutoDrop Notice email was sent ok, or
an error message if there was a problem.
You should also check that the
email was received at the other end; just because a message was sent doesn't mean
it will actually arrive.
Here's a list of return codes:
0 Success
1 An invalid parameter was supplied
2 Out of memory
3 xp_startmail or xp_startsmtp was not called
4 Bad host name, or no internet connection
5 Connect error
6 Secure connection error
7 MAPI functions are not available
100 Socket error.
Antivirus software may have blocked the outbound connection to the SMTP server.
Check the "SMTP Server:" field.
101 Socket timeout.
102 Unable to resolve the SMTP server hostname.
103 Unable to connect to the SMTP server.
104 Server error; response not understood.
Check the "SMTP Server:" field.
105 A TLS error occurred.
Check the "SMTP Authorization User Name:", "SMTP Authorization Password:" and
"SMTP Certificate Filespec:" fields.
421 Domain service not available, closing transmission channel.
450 Requested mail action not taken: mailbox unavailable.
451 Requested action not taken: local error in processing. Message may have
been rejected as spam.
452 Requested action not taken: insufficient system storage.
500 Syntax error, command unrecognized. (This may include errors such as
a command that is too long).
501 Syntax error in parameters or arguments.
502 Command not implemented.
503 Bad sequence of commands.
504 Command parameter not implemented.
511 Bad email address.
550 Requested action not taken: mailbox unavailable. For example, the mailbox is
not found, there is no access, or no relay is allowed.
551 User not local; please try forward-path.
552 Request mail action aborted: exceeded storage allocation.
553 Requested action not taken: mailbox name not allowed. For example, the
mailbox syntax is incorrect.
554 Transaction failed.
The message may have been rejected as spam.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Note: More information is required to complete the setup for Alert and AutoDrop Notice emails:
The Enforce the Alert Email Schedule lets you enable the automated Alert Email Schedule feature for this target database, which
in turn lets you turn the sending of Alert emails off and on at different times of the day.
Each Alert Email Schedule consists of 7 strings of 96 characters...
Each character represents one 15-minute period, from 12:00 midnight to 12:14:59.999 AM, 12:15 AM to 12:29:59.999 AM, and so on, 24 hours a day, 7 days a week.
You type "Y" or "y" for "yes, emails will be sent for Alert, All Clear and Cancelled messages issued during this 15-minute period".
Anything else means "no, emails will not be sent for Alert, All Clear and Cancelled messages issued during this 15-minute period".
Foxhound will change the "anything else" to "." or "^" when you click on Save.
Foxhound displays "^" and lower-case "y" to show you which column includes the current clock-on-the-wall time... but be careful, the display isn't updated automatically.
If you type too many characters in one day, Foxhound will chop off the extra characters on the right.
If you don't fill all the characters in one day, Foxhound will pad the day to the right with "." or "^" characters.
The button changes the day to all "Y" and "y" characters.
The button changes the day to all "." and "^" characters.
The button shifts all the characters to the left by one position, filling the right-most position with "." or "^"; in other words, it shifts but it doesn't wrap.
The button shifts all the characters to the right by one position, filling the left-most position with "." or "^"; in other words, it shifts but it doesn't wrap.
The button sets all the characters from 9:00 AM to 4:45 PM to "Y" or "y", and sets the rest to "." or "^".
The button sets all the characters from 5:00 AM to 8:45 PM to "Y" or "y", and sets the rest to "." or "^".
You can also copy-and-paste into each day's string of characters.
You must click if you want your changes saved.
Any one the Save buttons will save all the changes you have made anywhere on this page.
An alert is a message automatically displayed and/or sent via email whenever one or more target
database conditions match user-defined criteria.
The Monitor Options page
lets you specify these criteria for a particular target database. Individual criteria may
include a threshold amount and/or a duration or waiting period.
when a threshold has been reached (e.g. Alert #5) or
after a waiting period such as "for 10 or more recent samples" (e.g. Alert #2).
An all clear is issued when the alert criteria are no longer met.
If a waiting period is specified, Foxhound waits for
approximately half that time before issuing the all clear.
An active alert may be cancelled when
the alert criteria are changed on this page, in which case the alert testing process starts over,
(It doesn't matter what the change is. For example, even if the new alert condition is already
met when the change is made, if there is a waiting period it is honored before a new alert is issued.)
the alert is disabled on this page,
when sampling is stopped, in which case all active alerts are cancelled because
Foxhound is no longer gathering the information required the check the alert criteria, and
when ping-only sampling begins, in which case all active alerts (except Alert #1 Database
unavailable) are cancelled because Foxhound is no longer gathering the information
required the check the alert criteria.
The
button checks the "Alert enabled" boxes #1 through #34.
The
button unchecks the "Alert enabled" boxes #1 through #34.
The
button restores the "Alert enabled" boxes #1 through #34 to their previously saved settings.
You must click if you want your changes saved, including those made by Enable All and Disable All.
Any one the Save buttons will save all the changes you have made anywhere on this page.
Alert #1 - Database unresponsive - Foxhound has been unable to gather samples for [1m] or longer.
The term "unresponsive" means that from at least one client's point of view (Foxhound's)
the target database server is not responding at all.
The Alert #1 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "for xxx or longer" text box specifies an elapsed time duration of 10s or more,
using the "d h m s ms" input format; e.g., 10s for 10 seconds, 3d for 3 days, 1h 30m for 1 hour and 30 minutes.
Performance Tip: This Alert may mean the target database is down or catatonic; it definitely
means at least one client connection (Foxhound itself) can't get any work done.
If the target database is a High Availability secondary database and that database fails,
this Alert will draw your attention to that fact because Foxhound can't reconnect; it's not a failover situation.
When does Foxhound issue High Availability alerts?
If the target database is a High Availability primary database and a failover occurs (primary fails, secondary takes over),
If the target database is a High Availability secondary database and a failover occurs (primary fails, secondary takes over),
Alert #10 Partner unreachable
will be immediately issued because Foxhound remains connected to what has become the primary database, and there is no secondary.
Alert #31 Database updatable
will be immediately issued because Foxhound remains connected to what has become the primary database, and that database is updatable.
Alert #35 Separate ping failed
will be issued because the separate ping process tries and fails to connect to the secondary database.
If the failed partner (formerly the primary database) is restarted and it becomes the new secondary database,
Note that the separate ping process is connecting to a different database (the new secondary)
than the Foxhound sampling session itself (which remains connected to what
was originally the secondary database and is now the primary).
No Alert #11 ServerName change
will be issued because Foxhound remains connected to the same physical server (hence no ServerName change)
but that database has now become the updatable primary (hence the
Alert #31 Database updatable).
If the target database is a High Availability primary database and the secondary fails,
If the target database is a High Availability secondary database that has become the
primary after a failover, and an ALTER DATABASE SET PARTNER FAILOVER command has
been executed on the primary database to force a "user initiated role switch"
to put everything back the way it was,
Alert #30 Database read-only
will be issued because the target database has changed from updatable to read-only.
This Alert is issued if
the elapsed time since the last successful sample was recorded, or
the elapsed time since sampling (or Foxhound) was last restarted after being stopped,
whichever is shorter,
is greater than or equal to the threshold duration; e.g., 1m.
That means no Alert #1 will be produced for a brand-new sampling session
that hasn't recorded any successful samples yet no matter how much time has passed,
but checking for Alert #1 starts as soon as a successful sample is recorded or sampling is stopped and started.
The definition of "successful sample" depends on whether
Ping-Only Sampling
is in effect:
If Ping Only Sampling is in effect, a successful sample is one where the ping process was successful.
In this case, no other statistics are gathered, but the database is still available.
If Ping Only Sampling is not in effect, a successful sample is one where Foxhound was able
to execute the Heartbeat query and gather all the other performance statistics that make up a sample.
A subsequent All Clear #1 is issued when a subsequent successful sample is recorded;
there is no waiting period for this.
Alert #1 - Database unresponsive is supported for target databases running on all versions of SQL Anywhere that are supported by Foxhound,
and is based on Foxhound's ability to gather a sample or execute the ping process.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Performance Tip:
When Ping-Only Sampling is in effect, Alert #1 - Database unavailable will
let you know when Foxhound is unable to connect to the target database.
Alert #2 - Long heartbeat - The heartbeat time has been [1.0s] or longer for [10] or more recent samples.
The heartbeat time is how long it took for
Foxhound to execute the SELECT * FROM DUMMY heartbeat
or "canarian" query.
The Alert #2 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "has been xxx or longer" text box specifies an elapsed heartbeat response time duration of 0.1s or more,
using the "d h m s ms" input format; e.g., 10s for 10 seconds, 3d for 3 days, 1h 30m for 1 hour and 30 minutes.
The "for xxx or more recent samples" text box specifies a count of 1 or more samples
taken by the Foxhound Database Monitor.
Performance Tip: This Alert may mean response time (latency) is severely degraded: the
target database can't respond to simple SELECT * FROM DUMMY queries in a timely fashion.
This Alert is issued when the heartbeat time has met or exceeded the
threshold duration for the specified number of recent samples.
A subsequent All Clear #2 is issued when the heartbeat time has remained below the
threshold duration for approximately one-half the specified number of recent samples.
Alert #2 - Long heartbeat is supported for target databases running on all versions of SQL Anywhere that are supported by Foxhound,
and is based on Foxhound's measurement of the heartbeat query response time.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Alert #3 - Long sample time - The sample time has been [10.0s] or longer for [10] or more recent samples.
The sample time is how long it took for
Foxhound to gather all the performance data for one sample.
The Alert #3 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "has been xxx or longer" text box specifies an elapsed sample collection duration of 0.1s or more,
using the "d h m s ms" input format; e.g., 10s for 10 seconds, 3d for 3 days, 1h 30m for 1 hour and 30 minutes.
The "for xxx or more recent samples" text box specifies a count of 1 or more samples
taken by the Foxhound Database Monitor.
Performance Tip: This Alert may mean response time (latency) is severely degraded: the
target database can't respond to simple queries for SQL Anywhere performance statistics in a timely fashion.
This Alert is issued when the sample time has met or exceeded the
threshold duration for the specified number of recent samples.
A subsequent All Clear #3 is issued when the sample time has remained below the
threshold duration for approximately one-half the specified number of recent samples.
Alert #3 - Long sample time is supported for target databases running on all versions of SQL Anywhere that are supported by Foxhound,
and is based on Foxhound's measurement of the time required to gather all the performance data for one sample.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
This Alert is issued when the percentage of available CPU time used has met or exceeded the
threshold percentage for the specified number of recent samples.
A subsequent All Clear #4 is issued when the percentage of available CPU time used has remained below the
threshold percentage for approximately one-half the specified number of recent samples.
Alert #4 - CPU usage is supported for target databases running on SQL Anywhere version 7 and later,
and is based on the server-level NumLogicalProcessorsUsed, NumProcessorsAvail,
NumProcessorsMax and ProcessCPU properties.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
This Alert is issued when the free space on the disk drive holding the main (SYSTEM dbspace) file
has fallen below the threshold amount.
A subsequent All Clear #5 is issued as soon as the free space on the disk drive holding the main (SYSTEM dbspace) file
has risen above or equal to the threshold amount; there is no waiting period as with some other alerts.
Alert #5 - Database disk space is supported for target databases running on SQL Anywhere version 8 and later,
and is based on the properties returned by the sa_disk_free_space() procedure.
For target databases running on SQL Anywhere version 12 and earlier,
a user id with DBA authority is necessary for Foxhound to call the sa_disk_free_space()
procedure.
For target databases running on SQL Anywhere version 16 and later, the MANAGE ANY DBSPACE
privilege is required.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
This Alert is issued when the free space on the disk drive holding the temporary file
has fallen below the threshold amount.
A subsequent All Clear #6 is issued as soon as the free space on the disk drive holding the temporary file
has risen above or equal to the threshold amount; there is no waiting period as with some other alerts.
Alert #6 - Temp disk space is supported for target databases running on SQL Anywhere version 8 and later,
and is based on the properties returned by the sa_disk_free_space() procedure.
For target databases running on SQL Anywhere version 12 and earlier,
a user id with DBA authority is necessary for Foxhound to call the sa_disk_free_space()
procedure.
For target databases running on SQL Anywhere version 16 and later, the MANAGE ANY DBSPACE
privilege is required.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Alert #7 - Log disk space - The free disk space on the drive holding the transaction log file has fallen below [1GB].
The free disk space exists outside the file, and does not include free space inside the log file
(although there probably won't be much or any free space inside the log file due to it's
sequential-write-only nature).
The Alert #7 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "has fallen below xxx" text box specifies the amount of free disk space in bytes (minimum 1024),
k, M, G or T; e.g., 1000000, 100k, 200M, 5G, 1T.
Performance Tip: This Alert may indicate the transaction log file will soon run out of disk space.
This Alert is issued when the free space on the disk drive holding the transaction log file
has fallen below the threshold amount.
A subsequent All Clear #7 is issued as soon as the free space on the disk drive holding the transaction
log file has risen above or equal to the threshold amount; there is no waiting period as with some
other alerts.
Alert #7 - Log disk space is supported for target databases running on SQL Anywhere version 8 and later,
and is based on the properties returned by the sa_disk_free_space() procedure.
For target databases running on SQL Anywhere version 12 and earlier,
a user id with DBA authority is necessary for Foxhound to call the sa_disk_free_space()
procedure.
For target databases running on SQL Anywhere version 16 and later, the MANAGE ANY DBSPACE
privilege is required.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Alert #8 - Other disk space - The free disk space on one or more drives holding other database files has fallen below [1GB].
The term "other database files" means secondary dbspace files other than the SYSTEM dbspace, transaction log and temporary file.
The free disk space exists outside the files, and does not include free space inside the secondary dbspace files.
The Alert #8 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "has fallen below xxx" text box specifies the amount of free disk space in bytes (minimum 1024),
k, M, G or T; e.g., 1000000, 100k, 200M, 5G, 1T.
Performance Tip: This Alert may indicate one or more other database files will soon run out of disk space.
This Alert is issued when the free space on the disk drives holding the other database files
has fallen below the threshold amount.
A subsequent All Clear #8 is issued as soon as the free space on the disk drives holding the other database files
has risen above or equal to the threshold amount; there is no waiting period as with some other alerts.
Alert #8 - Other disk space is supported for target databases running on SQL Anywhere version 8 and later,
and is based on the properties returned by the sa_disk_free_space() procedure.
For target databases running on SQL Anywhere version 12 and earlier,
a user id with DBA authority is necessary for Foxhound to call the sa_disk_free_space()
procedure.
For target databases running on SQL Anywhere version 16 and later, the MANAGE ANY DBSPACE
privilege is required.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Alert #9 - Arbiter unreachable - The high availability target database has become disconnected from the arbiter server.
The "high availability target database" is the primary or secondary (mirror) database to which Foxhound
is connected; Foxhound cannot connect directly to the arbiter server.
The Alert #9 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
Performance Tip:
This Alert tells you when a High Availability setup has become vulnerable to
complete failure because the arbiter has become unreachable.
If the target database is a High Availability secondary database and a failover occurs (primary fails, secondary takes over),
Alert #10 Partner unreachable
will be immediately issued because Foxhound remains connected to what has become the primary database, and there is no secondary.
Alert #31 Database updatable
will be immediately issued because Foxhound remains connected to what has become the primary database, and that database is updatable.
Alert #35 Separate ping failed
will be issued because the separate ping process tries and fails to connect to the secondary database.
If the failed partner (formerly the primary database) is restarted and it becomes the new secondary database,
Note that the separate ping process is connecting to a different database (the new secondary)
than the Foxhound sampling session itself (which remains connected to what
was originally the secondary database and is now the primary).
No Alert #11 ServerName change
will be issued because Foxhound remains connected to the same physical server (hence no ServerName change)
but that database has now become the updatable primary (hence the
Alert #31 Database updatable).
If the target database is a High Availability primary database and the secondary fails,
If the target database is a High Availability secondary database that has become the
primary after a failover, and an ALTER DATABASE SET PARTNER FAILOVER command has
been executed on the primary database to force a "user initiated role switch"
to put everything back the way it was,
Alert #30 Database read-only
will be issued because the target database has changed from updatable to read-only.
A subsequent All Clear #9 is issued when the ArbiterState property becomes 'connected' again.
In particular, a subsequent All Clear #9 is issued when MirrorState = '' OR ArbiterState = 'connected' OR ArbiterState = ''.
Alert #9 - Arbiter unreachable is supported for target databases running on SQL Anywhere version 11 and later,
and is based on the database-level properties ArbiterState and MirrorState.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Alert #10 - Partner unreachable - The high availability target database has become disconnected from the partner database.
The "high availability target database" is the primary or secondary (mirror) database to which Foxhound
is connected, and the "partner database" is the other one; i.e., the secondary or primary.
The Alert #10 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
Performance Tip:
This Alert tells you when a High Availability setup has become vulnerable to
complete failure because one of the two partners has become unreachable.
If the target database is a High Availability secondary database and a failover occurs (primary fails, secondary takes over),
Alert #10 Partner unreachable
will be immediately issued because Foxhound remains connected to what has become the primary database, and there is no secondary.
Alert #31 Database updatable
will be immediately issued because Foxhound remains connected to what has become the primary database, and that database is updatable.
Alert #35 Separate ping failed
will be issued because the separate ping process tries and fails to connect to the secondary database.
If the failed partner (formerly the primary database) is restarted and it becomes the new secondary database,
Note that the separate ping process is connecting to a different database (the new secondary)
than the Foxhound sampling session itself (which remains connected to what
was originally the secondary database and is now the primary).
No Alert #11 ServerName change
will be issued because Foxhound remains connected to the same physical server (hence no ServerName change)
but that database has now become the updatable primary (hence the
Alert #31 Database updatable).
If the target database is a High Availability primary database and the secondary fails,
If the target database is a High Availability secondary database that has become the
primary after a failover, and an ALTER DATABASE SET PARTNER FAILOVER command has
been executed on the primary database to force a "user initiated role switch"
to put everything back the way it was,
Alert #30 Database read-only
will be issued because the target database has changed from updatable to read-only.
A subsequent All Clear #10 is issued when the PartnerState property becomes 'connected' again.
Alert #10 - Partner unreachable is supported for target databases running on SQL Anywhere version 11 and later,
and is based on the database-level PartnerState property.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Alert #11 - ServerName change - The real server name has changed to [server2], possibly because of an HA failover or OnDemand move.
The "real server name" is the SQL Anywhere server name created by the instance of the SQL Anywhere server executable when it starts; e.g., dbsrv16.exe -n partner1_demo
This real server name does not change while the server is running... but in an HA failover Foxhound will (re)connect
to a different instance of the SQL Anywhere server executable that has a different "real server name", hence the Alert.
The Alert #11 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
Performance Tip:
This Alert may indicate that a failover of the High Availability primary database
from one partner to the other has occurred.
If the target database is a High Availability secondary database and a failover occurs (primary fails, secondary takes over),
Alert #10 Partner unreachable
will be immediately issued because Foxhound remains connected to what has become the primary database, and there is no secondary.
Alert #31 Database updatable
will be immediately issued because Foxhound remains connected to what has become the primary database, and that database is updatable.
Alert #35 Separate ping failed
will be issued because the separate ping process tries and fails to connect to the secondary database.
If the failed partner (formerly the primary database) is restarted and it becomes the new secondary database,
Note that the separate ping process is connecting to a different database (the new secondary)
than the Foxhound sampling session itself (which remains connected to what
was originally the secondary database and is now the primary).
No Alert #11 ServerName change
will be issued because Foxhound remains connected to the same physical server (hence no ServerName change)
but that database has now become the updatable primary (hence the
Alert #31 Database updatable).
If the target database is a High Availability primary database and the secondary fails,
If the target database is a High Availability secondary database that has become the
primary after a failover, and an ALTER DATABASE SET PARTNER FAILOVER command has
been executed on the primary database to force a "user initiated role switch"
to put everything back the way it was,
Alert #30 Database read-only
will be issued because the target database has changed from updatable to read-only.
A subsequent All Clear #11 is issued when the ServerName property remains the same from one sample to the next,
and the ArbiterState and PartnerState properties are both 'connected' or both empty.
Alert #11 - ServerName change is supported for target databases running on SQL Anywhere version 10 and later,
and is based on the server-level ServerName property; e.g., dbsrv16.exe -n partner1_demo
Performance Tip:
The "server-level ServerName property" is not at all the same thing as the "ServerName connection parameter". One is a property, the other a parameter; one is at the server level, the other pertains to a connection. One is real, the other is [cough] "logical" :)
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Alert #13 - File fragmentation - There are [1000] or more fragments in the main database file.
File fragmentation pertains to the external structure of the physical disk file, not the internal structure
of the SQL Anywhere table and index data.
The Alert #13 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "xxx or more fragments" text box specifies a count of 2 or more physical file fragments
in the SYSTEM dbspace file.
Performance Tip:
This Alert may indicate that disk I/O is adversely affected... but maybe not, in the case of
RAID and SSD drives; internal table and index fragmentation may be more important.
This Alert is issued when the number of fragments has reached or exceeded the threshold amount.
A subsequent All Clear #13 is issued as soon as the number of fragments as fallen below the
threshold amount; there is no waiting period as with some other alerts.
Alert #13 - File fragmentation is supported for target databases running on SQL Anywhere version 8 and later,
and is based on the database-level DBFileFragments property.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Alert #14 - Unscheduled requests - The number of requests waiting to be processed has reached [5] or more for [10] or more recent samples.
A "request" is an atomic internal unit of work processed by the server for a connection, not a client-server communication request from a client application to the SQL Anywhere server.
The Alert #14 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "has reached xxx or more" text box specifies a count of 1 or more unscheduled requests.
The "for xxx or more recent samples" text box specifies a count of 1 or more samples
taken by the Foxhound Database Monitor.
Performance Tip:
This Alert may indicate that some performance bottleneck is preventing the database from processing
its workload.
The bottleneck may simply be a Max Req value that is too low (solution: increase the server -gn option), but the problem may be harder than that; for example, if the application design results in excessive blocking and/or too many long-running requests.
This Alert is issued when the number of unscheduled requests has reached or exceeded the
threshold amount for the specified number of recent samples.
A subsequent All Clear #14 is issued when the number of unscheduled requests has remained below the
threshold amount for approximately one-half the specified number of recent samples.
Alert #14 - Unscheduled requests is supported for target databases running on all versions of SQL Anywhere that are supported by Foxhound,
and is based on the server-level UnschReq property.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Alert #15 - Incomplete I/Os - The current number of incomplete file reads and/or writes has reached [2] or more for [10] or more recent samples.
An incomplete I/O is a file read or write that has been started but not completed.
The Alert #15 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "has reached xxx or more" text box specifies a count of 1 or more incomplete database
data file operations.
The "for xxx or more recent samples" text box specifies a count of 1 or more samples
taken by the Foxhound Database Monitor.
Performance Tip:
This Alert may indicate that there is a performance bottleneck caused by the inability of the disk system to keep up with database activity.
This Alert is issued when the number of incomplete file reads and/or writes has reached or exceeded
the threshold amount for the specified number of recent samples.
A subsequent All Clear #15 is issued when the number of incomplete file reads and/or writes has
remained below the threshold amount for approximately one-half the specified number of recent samples.
Alert #15 - Incomplete I/Os is supported for target databases running on SQL Anywhere 17,
and is based on the database-level CurrRead and CurrWrite properties.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Alert #16 - I/O operations - There have been [1000] or more disk and log I/O operations per second for [10] or more recent samples.
Disk and log I/O includes page-level input and output operations on the SYSTEM,
temporary and secondary dbspace files, plus pages written to the transaction log file.
Other files are excluded; e.g., non-dbspace files used by LOAD and UNLOAD statements and by
xp_read_file() and xp_write_file() procedure calls.
The Alert #16 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "have been xxx or more" text box specifies a count of 1 or more I/O operations per second
performed on the database data and transaction log files.
The "for xxx or more recent samples" text box specifies a count of 1 or more samples
taken by the Foxhound Database Monitor.
Performance Tip:
This Alert may indicate that heavy disk I/O is a performance bottleneck.
This Alert is issued when the number of I/O operations per second has reached or exceeded the
threshold amount for the specified number of recent samples.
A subsequent All Clear #16 is issued when the number of I/O operations per second has remained below the
threshold amount for approximately one-half the specified number of recent samples.
Alert #16 - I/O operations is supported for target databases running on all versions of SQL Anywhere that are supported by Foxhound,
and is based on the server-level DiskRead, DiskWrite and LogWrite properties for target databases running on SQL Anywhere versions 5 and 6,
and on the database-level DiskRead, DiskWrite and LogWrite properties for versions 7 and later.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Alert #17 - Checkpoint urgency - The Checkpoint Urgency has been [100] % or more for [10] or more recent samples.
Checkpoint Urgency is the percentage of the SET OPTION PUBLIC.CHECKPOINT_TIME value that has elapsed since the previous checkpoint.
The Alert #17 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "has been xxx % or more" text box specifies a checkpoint urgency percentage 1 or more,
which can exceed 100.
The "for xxx or more recent samples" text box specifies a count of 1 or more samples
taken by the Foxhound Database Monitor.
Performance Tip:
This Alert may indicate that SQL Anywhere is taking too long between checkpoints, or (more likely) that the CHECKPOINT_TIME option has been set to an unreasonably small value.
Before changing how often SQL Anywhere takes checkpoints, think twice! SQL Anywhere almost always does an excellent job of picking the right time to perform a checkpoint without your help.
This Alert is issued when the checkpoint urgency has reached or exceeded the threshold percentage
for the specified number of recent samples.
A subsequent All Clear #17 is issued when the checkpoint urgency has remained below the
threshold percentage for approximately one-half the specified number of recent samples.
Alert #17 - Checkpoint urgency is supported for target databases running on SQL Anywhere version 7 and later,
and is based on the database-level CheckpointUrgency property.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Alert #18 - Recovery urgency - The Recovery Urgency has been [1000] % or more for [10] or more recent samples.
Recovery Urgency is SQL Anywhere's estimate of the percentage of the SET OPTION PUBLIC.RECOVERY_TIME value that would be required to perform a recovery if the database was suddenly stopped and restarted without a checkpoint; in some cases it can rise far beyond 100%.
The Alert #18 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "has been xxx % or more" text box specifies a recovery urgency percentage 1 or more,
which can exceed 100.
The "for xxx or more recent samples" text box specifies a count of 1 or more samples
taken by the Foxhound Database Monitor.
Performance Tip:
This Alert may indicate that SQL Anywhere is taking too long between checkpoints, or (more likely) that the CHECKPOINT_TIME and/or RECOVERY_TIME options have been set to unreasonable values.
Before changing how often SQL Anywhere takes checkpoints, think twice! SQL Anywhere almost always does an excellent job of picking the right time to perform a checkpoint without your help.
This Alert is issued when the recovery urgency has reached or exceeded the threshold percentage
for the specified number of recent samples.
A subsequent All Clear #18 is issued when the recovery urgency has remained below the
threshold percentage for approximately one-half the specified number of recent samples.
Alert #18 - Recovery urgency is supported for target databases running on SQL Anywhere version 7 and later,
and is based on the database-level RecoveryUrgency property.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Alert #19 - Cache size - The cache has reached [100] % of its maximum size for [10] or more recent samples.
The "cache percentage of maximum" is based on the SQL Anywhere server's understanding of the
maximum amount of RAM it can use.
The Alert #19 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "cache has reached xxx % " text box specifies a percentage of the maximum cache size 1 to 100.
The "for xxx or more recent samples" text box specifies a count of 1 or more samples
taken by the Foxhound Database Monitor.
Performance Tip:
This Alert may indicate that insufficient memory in the database cache is a performance bottleneck.
However, you may want to disable this alert for target databases running on a dedicated server
where the cache size is always set to the maximum, or in a stable environment where the
cache size always grows to the maximum and remains there.
This Alert is issued when the cache percentage of maximum has reached or exceeded the threshold percentage
for the specified number of recent samples.
A subsequent All Clear #19 is issued when the cache percentage of maximum has remained below the
threshold percentage for approximately one-half the specified number of recent samples.
Alert #19 - Cache size< is supported for target databases running on SQL Anywhere version 7 and later,
and is based on the server-level CurrentCacheSize and MaxCacheSize properties.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Alert #20 - Cache satisfaction - The cache satisfaction (hits/reads) has fallen to [90] % or lower for [10] or more recent samples.
Cache satisfaction is an expression of how often a page lookup in the cache (CacheRead) was satisfied by
finding that page in the cache (CacheHits) as opposed to requiring an actual disk read.
The Alert #20 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "has fallen to xxx % " text box specifies a percentage cache satisfaction 1 to 99.
The "for xxx or more recent samples" text box specifies a count of 1 or more samples
taken by the Foxhound Database Monitor.
Performance Tip:
This Alert may indicate that insufficient memory in the database cache is a performance bottleneck.
This Alert is issued when the cache satisfaction has fallen to or below the threshold percentage
for the specified number of recent samples.
A subsequent All Clear #20 is issued when the cache satisfaction has remained above the
threshold percentage for approximately one-half the specified number of recent samples.
Alert #20 - Cache satisfaction is supported for target databases running on all versions of SQL Anywhere
that are supported by Foxhound,
and is based on the server-level CacheHits and CacheRead properties for target databases running
on SQL Anywhere versions 5 and 6,
and on the database-level CacheHits and CacheRead properties for versions 7 and later.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Alert #21 - Temp file usage - The total temporary file space used by all connections has been [1G] or larger for [10] or more recent samples.
Temporary pages are used for many purposes, most often to hold intermediate results during query processing. Even if there is no temporary file, as with an in-memory no write database, temporary space is allocated and used by the engine.
The Alert #21 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "has been xxx" text box specifies the amount of temporary file space in bytes (minimum 1024),
k, M, G or T; e.g., 1000000, 100k, 200M, 5G, 1T.
The "for xxx or more recent samples" text box specifies a count of 1 or more samples
taken by the Foxhound Database Monitor.
Performance Tip:
This Alert may indicate that runaway queries are a performance bottleneck.
This Alert is issued when the total temporary space used has reached or exceeded the threshold amount
for the specified number of recent samples.
A subsequent All Clear #21 is issued when the total temporary space used has remained below the
threshold amount for approximately one-half the specified number of recent samples.
Performance Tip:
The term "temporary file" is misleading and it should be renamed "temporary space" because the data
may or may not reside in the actual temporary file (which may not exist at all).
Alert #21 - Temp file usage is supported for target databases running on SQL Anywhere version 8 and later,
and is based on the database-level PageSize property and the sum of the connection-level TempFilePages property.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Alert #22 - Conn temp file usage - At least one single connection has used [500M] or more of temporary file space during [10] or more recent samples.
Temporary pages are used for many purposes, most often to hold intermediate results during query processing. Even if there is no temporary file, as with an in-memory no write database, temporary space is allocated and used by the engine.
The Alert #22 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "has been xxx" text box specifies the amount of temporary file space in bytes (minimum 1024),
k, M, G or T; e.g., 1000000, 100k, 200M, 5G, 1T.
The "during xxx or more recent samples" text box specifies a count of 1 or more samples
taken by the Foxhound Database Monitor.
Performance Tip:
This Alert may indicate that runaway queries are a performance bottleneck.
This Alert is issued when the maximum temporary space used by an individual connection
has reached or exceeded the threshold amount for the specified number of recent samples.
Foxhound does not check to see if it's the same connection each time a sample is gathered;
it could be different connections.
In other words, at least one connection meets or exceeds the threshold.
A subsequent All Clear #22 is issued when the maximum temporary space used by an individual connection
has remained below the threshold amount for approximately one-half the specified number of recent samples.
In other words, no connections meet or exceed the threshold.
Performance Tip:
The term "temporary file" is misleading and it should be renamed "temporary" because the data
may or may not reside in the actual temporary file (which may not exist at all).
Alert #22 - Conn temp file usage is supported for target databases running on SQL Anywhere
version 8 and later,
and is based on the database-level PageSize property and the connection-level TempFilePages property.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Alert #23 - Blocked connections - The number of blocked connections has reached [10] or more during [10] or more recent samples.
A blocked connection is a connection that cannot get any more work done because some other
connection has locked something this connection needs.
A blocked connection is not the same as a deadlock. In most cases, blocked connections wait indefinitely whereas deadlocks are instantly resolved when SQL Anywhere cancels one of the transactions involved.
The Alert #23 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "reached xxx or more" text box specifies a count of 1 or more blocked connections.
The "during xxx or more recent samples" text box specifies a count of 1 or more samples
taken by the Foxhound Database Monitor.
Performance Tip:
This Alert may indicate a serious performance bottleneck caused by locks being held too long; the
root cause may be an application program design error.
This Alert is issued when the number of blocked connections has reached or exceeded the threshold amount
for the specified number of recent samples.
A subsequent All Clear #23 is issued when the number of blocked connections has remained below the
threshold amount for approximately one-half the specified number of recent samples.
Alert #23 - Blocked connections is supported for target databases running on all versions of SQL Anywhere that are supported by Foxhound,
and is based on the connection-level BlockedOn property for target databases running on SQL Anywhere versions 5.5 through 16,
and on the connection-level BlockedOn, LockObjectType and LockObjectOID properties version 17.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Alert #24 - Conn blocking others - At least one single connection has blocked [5] or more other connections during [10] or more recent samples.
A blocked connection is a connection that cannot get any more work done because some other
connection has locked something this connection needs.
A blocked connection is not the same as a deadlock. In most cases, blocked connections wait indefinitely whereas deadlocks are instantly resolved when SQL Anywhere cancels one of the transactions involved.
The Alert #24 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "blocked xxx or more" text box specifies a count of 1 or more blocked connections.
The "during xxx or more recent samples" text box specifies a count of 1 or more samples
taken by the Foxhound Database Monitor.
Performance Tip:
This Alert may indicate a serious performance bottleneck caused by locks being held too long; the
root cause may be an application program design error.
This Alert is issued when the maximum number of connections blocked by another individual connection
has reached or exceeded the threshold amount for the specified number of recent samples.
Foxhound does not check to see if it's the same connection each time a sample is gathered;
it could be different connections.
In other words, at least one connection meets or exceeds the threshold.
A subsequent All Clear #24 is issued when the maximum number of connections blocked
by another individual connection
has remained below the threshold amount for approximately one-half the specified number of recent samples.
In other words, no connections meet or exceed the threshold.
Alert #24 - Conn blocking others is supported for target databases running on all versions of SQL Anywhere that are supported by Foxhound,
and is based on the connection-level BlockedOn property for target databases running on SQL Anywhere versions 5.5 through 16,
and on the connection-level BlockedOn, LockObjectType and LockObjectOID properties version 17.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Alert #25 - Locks - The number of locks has reached [1,000,000] or more during [10] or more recent samples.
Locks are a good thing; they keep data from being corrupted. Too many locks, maybe not so much, but
definition of "too many" is delightfully vague. For example, SQL Anywhere can handle millions of locks
but a single lock is all it takes to block a connection.
The Alert #25 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "has reached xxx or more" text box specifies a count of 1 or more locks.
The "during xxx or more recent samples" text box specifies a count of 1 or more samples
taken by the Foxhound Database Monitor.
Performance Tip:
This Alert may indicate that too many locks are being held for too long.
This Alert is issued when the number of locks has reached or exceeded the threshold amount
for the specified number of recent samples.
A subsequent All Clear #25 is issued when the number of locks has remained below the
threshold amount for approximately one-half the specified number of recent samples.
Alert #25 - Locks is supported for target databases running on SQL Anywhere 10 and later,
and is based on the database-level LockCount property.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Alert #26 - Connections - The number of connections has reached [1000] or more for [10] or more recent samples.
Simply put, a "connection" is a persistent two-way communication path between a client and a
SQL Anywhere database.
In the case of the SQL Anywhere server, the definition of "client" continues to evolve to include (and
sometimes exclude) internal processes, and so does the definition of "connection". For the most part,
however, connections are what exist between your client applications and the database.
Note that only database connections exist, not server connections. That becomes [cough] interesting when
you have two or more databases running on one server. For example, Foxhound displays a variety of
database-level properties (when they are available) and server-level properties (when the database-level
equivalents are not implemented by SQL Anywhere or not reliable).
The Alert #26 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "has reached xxx or more" text box specifies a count of 2 or more connections.
The "for xxx or more recent samples" text box specifies a count of 1 or more samples
taken by the Foxhound Database Monitor.
Performance Tip:
This Alert may indicate that heavy client load on the database is a performance bottleneck.
This Alert is issued when the number of connections has reached or exceeded the
threshold amount for the specified number of recent samples.
A subsequent All Clear #26 is issued when the number of connections has remained below the
threshold amount for approximately one-half the specified number of recent samples.
Alert #26 - Connections is supported for target databases running on all versions of SQL Anywhere that are supported by Foxhound,
and is based on the database-level ConnCount property.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
This Alert is issued when the maximum percentage of available CPU time
used by an individual connection
has reached or exceeded the threshold percentage for the specified number of recent samples.
Foxhound does not check to see if it's the same connection each time a sample is gathered;
it could be different connections.
In other words, at least one connection meets or exceeds the threshold.
A subsequent All Clear #27 is issued when the maximum percentage of available CPU time
used by an individual connection
has remained below the threshold percentage for approximately one-half the specified number of recent samples.
In other words, no connections meet or exceed the threshold.
Alert #27 - Connection CPU is supported for target databases running on SQL Anywhere 10 and later,
and is based on the connection-level ApproximateCPUTime property and
the server-level NumLogicalProcessorsUsed property.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Alert #28 - Long transaction - The transaction running time has reached [1m] or more for at least one connection during [10] or more recent samples.
The transaction running time is the length of time since the database was first modified by a
connection after a COMMIT or ROLLBACK.
While it is possible for a SELECT to acquire locks and thus block other connections (e.g., a shared
lock obtained by a SELECT will block an ALTER TABLE), a SELECT does not
count as a modification as far as the Transaction Time is concerned.
In other words, a SELECT does not start a transaction.
The Alert #28 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "has reached xxx or more" text box specifies a transaction running time duration of 1s or more,
using the "d h m s ms" input format; e.g., 10s for 10 seconds, 3d for 3 days, 1h 30m for 1 hour and 30 minutes.
The "for xxx or more recent samples" text box specifies a count of 1 or more samples
taken by the Foxhound Database Monitor.
Performance Tip: This Alert may indicate that a long-running transaction is a
performance bottleneck.
This Alert is issued when the maximum transaction running time an individual connection
has reached or exceeded the threshold percentage for the specified number of recent samples.
Foxhound does not check to see if it's the same connection each time a sample is gathered;
it could be different connections.
In other words, at least one connection meets or exceeds the threshold.
Note that the AutoDrop and Alert processes are completely independent;
i.e., if the Alert #28 Long transaction criteria are met then the Alert will appear;
it doesn't matter what the AutoDrop #3 Long transaction criteria are, and vice versa.
A subsequent All Clear #28 is issued when the maximum transaction running time an individual connection
has remained below the threshold percentage for approximately one-half the specified number of recent samples.
In other words, no connections meet or exceed the threshold.
Alert #28 - Long transaction is supported for target databases running on SQL Anywhere 8 and later,
and is based on the connection-level TransactionStartTime property.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
This Alert is issued when the number of cache panics has reached or exceeded the
threshold amount for the specified number of recent samples.
A subsequent All Clear #29 is issued when the number of cache panics has remained below the
threshold amount for approximately one-half the specified number of recent samples.
Alert #29 - Cache panics is supported for target databases running on SQL Anywhere version 9 and later,
and is based on the server-level CachePanics property.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Alert #30 - Database read-only - The target database has changed from accepting updates to read-only processing.
A change in the database-level ReadOnly property (between 'On' for read-only processing and 'Off' for accepting updates)
is almost always an indirect indicator that a significant event has occurred in a SQL Anywhere High Availability setup.
The Alert #30 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
Performance Tip:
This Alert may not be as useful as Alert #31 Database updatable which warns of the opposite change.
If Alert #30 and #31 are both enabled (the default), one or the other will always be in effect after the first ReadOnly change occurs.
If the target database is a High Availability secondary database and a failover occurs (primary fails, secondary takes over),
Alert #10 Partner unreachable
will be immediately issued because Foxhound remains connected to what has become the primary database, and there is no secondary.
Alert #31 Database updatable
will be immediately issued because Foxhound remains connected to what has become the primary database, and that database is updatable.
Alert #35 Separate ping failed
will be issued because the separate ping process tries and fails to connect to the secondary database.
If the failed partner (formerly the primary database) is restarted and it becomes the new secondary database,
Note that the separate ping process is connecting to a different database (the new secondary)
than the Foxhound sampling session itself (which remains connected to what
was originally the secondary database and is now the primary).
No Alert #11 ServerName change
will be issued because Foxhound remains connected to the same physical server (hence no ServerName change)
but that database has now become the updatable primary (hence the
Alert #31 Database updatable).
If the target database is a High Availability primary database and the secondary fails,
If the target database is a High Availability secondary database that has become the
primary after a failover, and an ALTER DATABASE SET PARTNER FAILOVER command has
been executed on the primary database to force a "user initiated role switch"
to put everything back the way it was,
Alert #30 Database read-only
will be issued because the target database has changed from updatable to read-only.
A subsequent All Clear #30 is issued when the ReadOnly property changes from 'On' to 'Off'.
Alert #30 - Database read-only is supported for target databases running on SQL Anywhere version 8 and later,
and is based on the database-level ReadOnly property.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Alert #31 - Database updatable - The target database has changed from read-only processing to accepting updates.
A change in the database-level ReadOnly property (between 'On' for read-only processing and 'Off' for accepting updates)
is almost always an indirect indicator that a significant event has occurred in a SQL Anywhere High Availability setup.
The Alert #31 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
Performance Tip:
This Alert is useful if you want to be warned when a read-only secondary database suddenly becomes updatable
after a High Availability failover.
If Alert #30 and #31 are both enabled (the default), one or the other will always be in effect after the first ReadOnly change occurs.
If the target database is a High Availability secondary database and a failover occurs (primary fails, secondary takes over),
Alert #10 Partner unreachable
will be immediately issued because Foxhound remains connected to what has become the primary database, and there is no secondary.
Alert #31 Database updatable
will be immediately issued because Foxhound remains connected to what has become the primary database, and that database is updatable.
Alert #35 Separate ping failed
will be issued because the separate ping process tries and fails to connect to the secondary database.
If the failed partner (formerly the primary database) is restarted and it becomes the new secondary database,
Note that the separate ping process is connecting to a different database (the new secondary)
than the Foxhound sampling session itself (which remains connected to what
was originally the secondary database and is now the primary).
No Alert #11 ServerName change
will be issued because Foxhound remains connected to the same physical server (hence no ServerName change)
but that database has now become the updatable primary (hence the
Alert #31 Database updatable).
If the target database is a High Availability primary database and the secondary fails,
If the target database is a High Availability secondary database that has become the
primary after a failover, and an ALTER DATABASE SET PARTNER FAILOVER command has
been executed on the primary database to force a "user initiated role switch"
to put everything back the way it was,
Alert #30 Database read-only
will be issued because the target database has changed from updatable to read-only.
A subsequent All Clear #31 is issued when the ReadOnly property changes from 'Off' to 'On'.
Alert #31 - Database updatable is supported for target databases running on SQL Anywhere version 8 and later,
and is based on the database-level ReadOnly property.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Alert #32 - Rollback log usage - The total rollback log space used by all connections has been [1G] or larger for [10] or more recent samples.
A separate rollback log, also known as an undo log or row level undo log, is maintained
for each connection to hold a sequential record of the reverse operations
that would undo the logical changes made to the database by this connection
since the last COMMIT or ROLLBACK was executed on the connection.
The total rollback log space is similar to but different from the total number of uncommitted operations
(see Alert #33);
both measure of how much work has been started but not yet finished in this database.
The Alert #32 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "has fallen below xxx" text box specifies the amount of rollback log space in bytes (minimum 1024),
k, M, G or T; e.g., 1000000, 100k, 200M, 5G, 1T.
The "for xxx or more recent samples" text box specifies a count of 1 or more samples
taken by the Foxhound Database Monitor.
Performance Tip:
This Alert is useful if you want to be warned when a large amount of work is in progress but not yet committed to the database.
The automatic recovery stage of server startup may take a long time if the server suddenly fails and is then restarted.
If an individual transaction is responsible for a lot of the space usage, that transaction may take a long time to roll back if it fails.
The final checkpoint stage of a normal server shutdown may also take a long time
while the changes recorded in a large rollback log are being reversed.
This Alert is issued when the total rollback log space has met or exceeded the
threshold amount for the specified number of recent samples.
A subsequent All Clear #32 is issued when the total rollback log space has remained below the
threshold amount for approximately one-half the specified number of recent samples.
Alert #32 - Rollback log usage is supported for target databases running on all versions of SQL Anywhere that are supported by Foxhound,
and is based on the database-level PageSize property and the sum of the connection-level RollbackLogPages property.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Alert #33 - Uncommitted operations - The total number of uncommitted operations for all connections has reached [1,000,000] or more during [10] or more recent samples.
The total number of uncommitted operations is similar to but different from the total rollback log space
(see Alert #32);
both measure of how much work has been started but not yet finished in this database.
The Alert #33 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "reached xxx or more" text box specifies a count of 1 or more uncommitted operations.
The "during xxx or more recent samples" text box specifies a count of 1 or more samples
taken by the Foxhound Database Monitor.
Performance Tip:
This Alert is useful if you want to be warned when a large amount of work is in progress but not yet committed to the database.
The automatic recovery stage of server startup may take a long time if the server suddenly fails and is then restarted.
If an individual transaction is responsible for a lot of uncommitted operations, that transaction may take a long time to roll back if it fails.
Performance Tip:
The count of Uncommitted operations includes (and may be exactly equal to) the number of uncommitted
row-level inserts, updates and deletes.
The count of Uncommitted operations may be larger than the number of INSERT, UPDATE and DELETE
statements because one statement can affect many rows.
If a single row is inserted, then updated twice and finally deleted, for example, that counts as
four Uncommitted operations.
If a single row matches the WHERE clause of an UPDATE statement but all of the new column values in the
SET clause are the same as the current values in the row, that row is not updated and the operation
is not counted as an Uncommitted operation.
A table-level schema lock obtained by a SELECT statement is not counted as an Uncommitted operation
even though the lock is not cleared until a subsequent commit or rollback (and may thus be regarded
as "uncommitted").
This Alert is issued when the total number of uncommitted operations has met or
exceeded the threshold number for the specified number of recent samples.
A subsequent All Clear #33 is issued when the total number of uncommitted operations has remained below the
threshold number for approximately one-half the specified number of recent samples.
Alert #33 - Uncommitted operations is supported for target databases running on all versions of SQL Anywhere that are supported by Foxhound,
and is based on the sum of the connection-level UncommitOp property.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Alert #34 - Long uncommitted - The number of uncommitted operations has reached [1,000,000] or more while the transaction running time has reached [1m] or more for at least one connection.
The Alert #34 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "reached xxx or more" text box specifies a count of 1 or more uncommitted operations.
The "has reached xxx or more" text box specifies a transaction running time duration of 1s or more,
using the "d h m s ms" input format; e.g., 10s for 10 seconds, 3d for 3 days, 1h 30m for 1 hour and 30 minutes.
Performance Tip:
This Alert is useful if you want to be warned when a single connection is sucking all the air out of the room;
i.e., when a long-running transaction has a performed a large amount of work that is not yet committed to the database.
Performance Tip:
The count of Uncommitted operations includes (and may be exactly equal to) the number of uncommitted
row-level inserts, updates and deletes.
The count of Uncommitted operations may be larger than the number of INSERT, UPDATE and DELETE
statements because one statement can affect many rows.
If a single row is inserted, then updated twice and finally deleted, for example, that counts as
four Uncommitted operations.
If a single row matches the WHERE clause of an UPDATE statement but all of the new column values in the
SET clause are the same as the current values in the row, that row is not updated and the operation
is not counted as an Uncommitted operation.
A table-level schema lock obtained by a SELECT statement is not counted as an Uncommitted operation
even though the lock is not cleared until a subsequent commit or rollback (and may thus be regarded
as "uncommitted").
This Alert is issued when the following conditions are both met:
The number of uncommitted operations for a single transaction on a single connection has met or exceeded the threshold number, and
the running time of that transaction has met or exceeded the threshold amount.
A subsequent All Clear #34 is issued as soon as one or the other or both of those conditions
are no longer met; there is no waiting period as with some other alerts.
The transaction running time
is the length of time since the database was first modified by this connection after a COMMIT or ROLLBACK.
Note that while it is possible for a SELECT to acquire locks and thus block other connections (e.g., a shared
lock obtained by a SELECT will block an ALTER TABLE), a SELECT does not
count as a modification as far as the Transaction Time is concerned.
In other words, a SELECT does not start a transaction.
Alert #34 - Long uncommitted is supported for target databases running on SQL Anywhere 8 and later,
and is based on the connection-level UncommitOp and TransactionStartTime properties.
Note that the AutoDrop and Alert processes are completely independent; there is no correlation. I.e., if the Alert #34 Long uncommitted
criteria are met then the Alert will appear; it doesn't matter what the AutoDrop #3 Long transaction criteria are, and vice versa.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Alert #35 - Separate ping failed - Foxhound has been unable to make a separate ping connection to the target database for [10] or more recent samples.
Foxhound provides an optional custom "ping" process to test separate connections to the target database;
see 16. Ping Settings
Performance Tip:
Alert #35 - Separate ping failed may be used to let you know when the target database is
not accepting new connections even though Foxhound remains connected and is successfully gathering sample data.
This is different from Alert #1 - Database unavailable which is only issued when Foxhound itself cannot
connect to the target database to gather a sample or perform Ping-Only sampling.
The Alert #35 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "for xxx or more recent samples" text box specifies a count of 1 or more samples
taken by the Foxhound Database Monitor.
This Alert is issued if Foxhound is successfully gathering other sample data
but has not been able to make a separate ping connection to the target database
(see Include Separate Ping with each successful sample).
A subsequent All Clear is issued as soon as Foxhound is able to make a separate ping connection
to the target database when recording a successful sample; there is no waiting period as with some other alerts.
Alert #35 - Separate ping failed is supported for target databases running on all versions of SQL Anywhere that are supported by Foxhound,
and is based on Foxhound's ability to gather a sample and execute the ping process.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
The Enforce the AutoDrop Schedule lets you enable the automated AutoDrop Schedule feature for this target database, which
in turn lets you turn the AutoDrop process off and on at different times of the day.
Note: There is no separate "AutoDrop Email Schedule" feature.
Each AutoDrop Schedule consists of 7 strings of 96 characters...
Each character represents one 15-minute period, from 12:00 midnight to 12:14:59.999 AM, 12:15 AM to 12:29:59.999 AM, and so on, 24 hours a day, 7 days a week.
You type "Y" or "y" for "yes, connections will be subject to the AutoDrop process during this 15-minute period".
Anything else means "no, connections will not be subject to the AutoDrop process during this 15-minute period".
Foxhound will change the "anything else" to "." or "^" when you click on Save.
Foxhound displays "^" and lower-case "y" to show you which column includes the current clock-on-the-wall time... but be careful, the display isn't updated automatically.
If you type too many characters in one day, Foxhound will chop off the extra characters on the right.
If you don't fill all the characters in one day, Foxhound will pad the day to the right with "." or "^" characters.
The button changes the day to all "Y" and "y" characters.
The button changes the day to all "." and "^" characters.
The button shifts all the characters to the left by one position, filling the right-most position with "." or "^"; in other words, it shifts but it doesn't wrap.
The button shifts all the characters to the right by one position, filling the left-most position with "." or "^"; in other words, it shifts but it doesn't wrap.
The button sets all the characters from 9:00 AM to 4:45 PM to "Y" or "y", and sets the rest to "." or "^".
The button sets all the characters from 5:00 AM to 8:45 PM to "Y" or "y", and sets the rest to "." or "^".
You can also copy-and-paste into each day's string of characters.
You must click if you want your changes saved.
Any one the Save buttons will save all the changes you have made anywhere on this page.
AutoDrop processing differs from Alert processing:
AutoDrop processing is only performed on target databases running on SQL Anywhere Version 9 and above.
The LoginTime connection property is not available on earlier versions so Foxhound cannot uniquely
identify different connections with 100% safety.
Child connections (the ParentConnection property is not zero) and
internal connections (the Userid property is empty) are ignored by AutoDrop processing.
When a connection is dropped by AutoDrop processing, it is a one-time event, whereas when
an Alert comes into effect it is a continuing condition. This means that while Alerts messages
have corresponding All Clear messages, AutoDrop messages do not.
AutoDrop tracking is immediately cancelled whenever the connection sinks below the tracking
threshold, whereas an All Clear may or may not be issued immediately after an Alert condition is no longer satisfied.
AutoDrop tracking is immediately cancelled whenever a sample is lost; e.g., when Foxhound could not
connect to the target database.
If AutoDrop tracking is in progress when you change the corresponding AutoDrop threshold, the
new threshold is immediately applied and tracking may or may not continue depending on the threshold.
This differs from Alert tracking which is immediately cancelled whenever the corresponding Alert
threshold is changed, no matter what the new threshold is.
Foxhound will only make one attempt to AutoDrop a connection whether that attempt works or not.
Note that a dropped connection may keep running for a while as SQL Anywhere rolls back
its work even though the client application has been disconnected.
The
button checks the "AutoDrop enabled" boxes #1 through #6.
The
button unchecks the "AutoDrop enabled" boxes #1 through #6.
The
button restores the "AutoDrop enabled" boxes #1 through #6 to their previously saved settings.
A user id with DBA authority is necessary for Foxhound to implement the AutoDrop feature
on target databases running on versions 12 and earlier of SQL Anywhere.
For version 16 target databases the DROP CONNECTION privilege is required.
You must click if you want your changes saved, including those made by Enable All and Disable All.
Any one the Save buttons will save all the changes you have made anywhere on this page.
AutoDrop #1 - Blocking others - Automatically drop each connection that has been blocking [5] or more other connections for [10] or more recent samples.
The AutoDrop #1 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "blocking xxx or more" text box specifies a count of 1 or more blocked connections.
The "for xxx or more recent samples" text box specifies a count of 1 or more samples
taken by the Foxhound Database Monitor.
AutoDrop #1 - Blocking others is supported for target databases running on all versions of SQL Anywhere that are supported by Foxhound,
and is based on the connection-level BlockedOn property for target databases running on SQL Anywhere versions 5.5 through 16,
and on the connection-level BlockedOn, LockObjectType and LockObjectOID properties version 17.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
AutoDrop #2 - Blocked by other - Automatically drop each connection that has been blocked by another connection for [10] or more recent samples.
The AutoDrop #2 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "for xxx or more recent samples" text box specifies a count of 1 or more samples
taken by the Foxhound Database Monitor.
AutoDrop #2 - Blocked by other is supported for target databases running on all versions of SQL Anywhere that are supported by Foxhound,
and is based on the connection-level BlockedOn property for target databases running on SQL Anywhere versions 5.5 through 16,
and on the connection-level BlockedOn, LockObjectType and LockObjectOID properties version 17.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
AutoDrop #3 - Long transaction - Automatically drop each connection with a transaction that has been running for [10m] or longer.
The AutoDrop #3 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "for xxx or longer" text box specifies a transaction running time duration of 1s or more,
using the "d h m s ms" input format; e.g., 10s for 10 seconds, 3d for 3 days, 1h 30m for 1 hour and 30 minutes.
The transaction running time
is the length of time since the database was first modified by this connection after a COMMIT or ROLLBACK.
Note that while it is possible for a SELECT to acquire locks and thus block other connections (e.g., a shared
lock obtained by a SELECT will block an ALTER TABLE), a SELECT does not
count as a modification as far as the Transaction Time is concerned.
In other words, a SELECT does not start a transaction.
AutoDrop #3 - Long transaction is supported for target databases running on SQL Anywhere 8 and later,
and is based on the connection-level TransactionStartTime property.
Note that the AutoDrop and Alert processes are completely independent; there is no correlation. I.e., if the AutoDrop #3 Long transaction
criteria are met that AutoDrop will be processed; it doesn't matter what the Alert #28 Long transaction or Alert #34 Long uncommitted criteria are, and vice versa.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
AutoDrop #4 - Temp file usage - Automatically drop each connection that uses [512M] or more of temporary file space for [10] or more recent samples.
The AutoDrop #4 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "uses xxx or more" text box specifies the amount of temporary space in bytes (minimum 1024),
k, M, G or T; e.g., 1000000, 100k, 200M, 5G, 1T.
The "for xxx or more recent samples" text box specifies a count of 1 or more samples
taken by the Foxhound Database Monitor.
AutoDrop #4 - Temp file usage is supported for target databases running on SQL Anywhere version 8 and later,
and is based on the database-level PageSize property and the connection-level TempFilePages property.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
AutoDrop #5 - CPU usage - Automatically drop each connection that uses [25] % or more of approximate CPU time for [10] or more recent samples.
The AutoDrop #5 enabled checkbox specifies whether or not you want Foxhound
to check for this condition.
The "uses xxx % or more" text box specifies a percentage of total available CPU time 1 to 100.
The "for xxx or more recent samples" text box specifies a count of 1 or more samples
taken by the Foxhound Database Monitor.
AutoDrop #5 - CPU usage is supported for target databases running on SQL Anywhere 10 and later,
and is based on the connection-level ApproximateCPUTime property and
the server-level NumLogicalProcessorsUsed property.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
The Do-Not-AutoDrop lists let you divide connections in two broad categories:
ordinary connections which should never, ever do bad things like block dozens of other connections, versus
important connections which should never, ever be dropped by any automatic process no matter what they are doing.
The Do-Not-AutoDrop lists let you protect important connections from being dropped by the AutoDrop process,
while leaving you free to specify AutoDrop criteria that apply to ordinary connections.
Do-Not-AutoDrop User Id List: Exclude this semicolon-separated list of user ids from being AutoDropped: [xxx;xxx]
The Do-Not-AutoDrop User Id List enabled checkbox specifies whether or not you want Foxhound
to check user ids against this list before dropping any connections.
Use semicolons to separate multiple user ids, and don't include any extra spaces; for example:
g.mikhailov;e.reid;n.simpson;x.wang;c.ryan
Note that Foxhound already excludes the following connections; you don't have to specify them in either Do-Not-AutoDrop list:
The AutoDrop process does not touch Foxhound's own connections; i.e., AutoDrop ignores connections names that begin with "Foxhound".
The AutoDrop process does not touch internal connections; i.e., AutoDrop ignores connections where the UserID is empty.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
Do-Not-AutoDrop Connection Name List: Exclude this semicolon-separated list of connection names from being AutoDropped: [xxx;xxx]
The Do-Not-AutoDrop Connection Name List enabled checkbox specifies whether or not you want Foxhound
to check connection names against this list before dropping any connections.
Use semicolons to separate multiple connection names, and don't include any extra spaces; for example:
app;payroll
Note that Foxhound already excludes the following connections; you don't have to specify them in either Do-Not-AutoDrop list:
The AutoDrop process does not touch Foxhound's own connections; i.e., AutoDrop ignores connections names that begin with "Foxhound".
The AutoDrop process does not touch internal connections; i.e., AutoDrop ignores connections where the UserID is empty.
You must click if you want your changes saved.
Any one of the Save buttons will save all the changes you have made anywhere on this page.
The Change Target Settings section lets you
change various settings on the target database servers to be more or less favorable
to the recording of data for Foxhound to display on the Monitor, History and
Connection History pages.
Performance Tip:
Changes to these server options on a High Availability primary database or a Read-Only Scale-Out root database
will not be automatically transmitted to a secondary or copy database.
However, since these are server options rather than database options, you can use the Favorable? field
on the secondary or copy database to make the same changes even though the Foxhound connections to those databases are read-only.
The Favorable Current Setting? column is refreshed when the Monitor Options
page is displayed and whenever one of the Yes / No buttons is pressed:
Yes means the setting is favorable to Foxhound,
No means the setting is not favorable, and
[not available] means sampling is stopped, the target database is not available, or the SQL
Anywhere version used to run the target database does not support the setting.
Performance Tip:
After a High Availability failover, it is possible for the Favorable? field on the
Monitor page for the secondary database to show different values from the Change Target Settings
section on the Monitor Options page for the "same" database (which isn't actually the same any more).
If the target database is a High Availability secondary database and
a failover occurs (primary fails, secondary takes over), the Favorable Current Settings?
column may show [not available].
The reason for this is that the Monitor Options - Change Target Settings section attempts to open
a new connection to the secondary database, and the database that used to be the secondary is now
the primary so there's no secondary database available. The Foxhound sampling session, however,
remains connected to the original database (once the secondary, now the primary) so there is an
apparent inconsistency between Favorable Current Settings? showing [not available], and the
Foxhound Monitor page showing that everything is OK.
But wait, there's more! If the failed database that was the original primary database is restarted,
it will become the new secondary database, and the Favorable Current Settings? column will show
actual values rather than [not available]... but those values will be coming from a different database
than the Foxhound sampling session is showing. That's because the Monitor Options - Change Target
Settings section opens a new connection to the secondary database, and the Foxhound Monitor session
remains connected to the original database (once the secondary, now the primary).
The and buttons let you
immediately change the corresponding setting, but they're disabled if the setting is not available.
Performance Tip:
Changes to these server options on a High Availability primary database or a
Read-Only Scale-Out root database will not be automatically transmitted to a secondary or copy database.
However, since these are server options rather than database options, you can use the Change Target Settings
feature to make the same changes to the secondary or copy database even though the Foxhound connections to those
databases are read-only.
The RememberLastPlan server option controls whether or not anything is displayed
in the following connection-level field on the Monitor, History and
Connection History pages:
Last Plan Text
Changes to RememberLastPlan affect both new and existing connections.
You can also enable RememberLastPlan server option as follows:
Specify the -zp server command line option when starting the target database.
- or -
CALL sa_server_option ( 'RememberLastPlan', 'YES' ) on the target database.
A user id with DBA authority is necessary for Foxhound to call the sa_server_option() procedure to set the
RememberLastPlan option for target databases running on versions 12 and earlier of SQL Anywhere.
For version 16 target databases the SERVER OPERATOR privilege is required.
The RememberLastPlan server option is supported by target databases running on SQL Anywhere version 9 and later.
The RememberLastStatement server option controls whether or not anything is displayed
in the connection-level fields on the Monitor, History and
Connection History pages:
Last Statement
Blocked Statement
You can also enable RememberLastStatement server option as follows:
Specify the -zl server command line option when starting the target database.
If that doesn't work, try turning off client statement caching on the target database:
SET TEMPORARY OPTION MAX_CLIENT_STATEMENTS_CACHED = '0';
- or -
SET OPTION PUBLIC.MAX_CLIENT_STATEMENTS_CACHED = '0';
Performance Tip:
RememberLastStatement is far more useful than RememberLastPlan and RequestTiming.
Changes to RememberLastStatement affect both new and existing connections.
A user id with DBA authority is necessary for Foxhound to call the sa_server_option() procedure to set the
RememberLastStatement option for target databases running on versions 12 and earlier of SQL Anywhere.
For version 16 target databases the SERVER OPERATOR privilege is required.
The RememberLastStatement server option is supported by target databases running on SQL Anywhere version 8 and later.
The RequestTiming server option controls whether or not anything is displayed
in the following connection-level columns on the Monitor, History and
Connection History pages:
Throughput... Req
Busy
Waiting
Waiting Time
You can also enable RequestTiming server option as follows:
Specify the -zt server command line option when starting the target database.
- or -
CALL sa_server_option ( 'RequestTiming', 'YES' ) on the target database.
The RequestTiming setting controls the following SQL Anywhere statistical properties that Foxhound uses in calculations:
ReqTimeActive
ReqTimeBlockContention
ReqTimeBlockIO
ReqTimeBlockLock
ReqTimeUnscheduled
Changes to RequestTiming affect new connections, and they may or may not immediately affect existing connections as follows:
Changing RequestTiming from No to Yes will not immediately affect existing connections.
Changing RequestTiming from Yes to No may or may not immediately affect existing connections,
depending on the version of SQL Anywhere used for the target database.
A user id with DBA authority is necessary for Foxhound to call the sa_server_option() procedure to set the
RequestTiming option for target databases running on versions 12 and earlier of SQL Anywhere.
For version 16 target databases the SERVER OPERATOR privilege is required.
The RequestTiming server option is supported by target databases running on SQL Anywhere version 9 and later.
Monitor DEDICATED_TASK Option: Instruct the Foxhound Monitor sampling process to set DEDICATED_TASK option ON for the connection to the target database.
When this feature is in effect, Foxhound's own connection from the
Monitor process to the target database will be given a dedicated request-handling task
by the SQL Anywhere server running the target database.
This means Foxhound will be more likely to be able to gather samples when the target server
is extremely busy, but it also means the target server will have one fewer
request-handling tasks available to service other connections.
Here's how to turn it on:
Check the "Enable" checkbox for a target database running on SQL Anywhere version 9.0.1 or later.
Click on one of the Save buttons.
The Foxhound Monitor process will then issue the
SET TEMPORARY OPTION DEDICATED_TASK = ON;
command and record the result.
When the Monitor Options page is redisplayed, the result will be displayed:
SET OK
or an error message.
For target databases running on SQL Anywhere versions 12 and earlier, a user id with DBA authority is necessary for Foxhound to set the DEDICATED_TASK option.
For target databases running on SQL Anywhere versions 16 or later, the SET ANY SYSTEM OPTION system privilege is required.
Here's how to turn it off:
Uncheck the "Enable" checkbox.
Click on one of the Save buttons.
Click on the "Stop Sampling" button on the Foxhound Monitor page.
When you see "Sampling stopped", click on the "Start Sampling" button.
Because the "Enable" checkbox is now unchecked when the Foxhound Monitor connects to
the target database to begin sampling, the DEDICATED_TASK option defaults to OFF.
Monitor Connection Name: Set the connection name template for the connections from the Foxhound Monitor process to the target database.
This template is used to create the ConnectionName parameter value used by Foxhound's connection from the Monitor process.
If the template contains the substring nnnn (as in the default Foxhound-Monitor-nnnn) the nnnn substring
is replaced at runtime by the Windows Process Identifier (PID) of the SQL Anywhere dbsrv16.exe or dbsrv17.exe process
that is running the Foxhound database.
This makes it easier to exactly identify where this connection is coming
from when there are a large number of target databases and Foxhound processes running.
These settings control how Foxhound uses a custom "ping" process to test separate connections to the target database.
Each time the ping process runs it opens a new connection to the target database via the embedded SQL interface,
issues a SELECT @@SPID command and then immediately disconnects.
This is different from the Foxhound Monitor process which connects to the target database via ODBC
and keeps that connection open while it collects multiple samples.
Note that the Foxhound ping process does not use the dbping.exe utility that ships with SQL Anywhere,
nor does it use the ODBC interface that is used to gather sample data.
Also note that the separate ping process "uses up" another SQL Anywhere connection number each time it runs,
which is once approximately every 10 seconds for each target database.
Perform Ping-Only Sampling: Run the Foxhound Ping process without gathering any other sample data.
The primary purpose of Ping-Only Sampling is to check for Alert #1 Database unavailable
without storing a lot of other data.
Performance Tip: You can also switch back-and-forth to Ping-Only Sampling on a scheduled basis using section
5. Sample Schedule.
The Foxhound Monitor connection to the target database is not required for ping-only sampling.
If a Foxhound Monitor connection exists when ping-only sampling begins, it becomes idle; it is not automatically
dropped by Foxhound but it's OK if you drop it.
Note: The following sections have no effect when Ping-Only Sampling is performed
because Foxhound doesn't gather other sample data:
5. Sample Schedule regardless of any 'P' characters in the schedule strings.
Include Separate Ping: Specify whether (and when) to include the Foxhound Ping process while Foxhound is gathering other sample data:
Include Separate Ping with each successful sample:
Run the ping process after successfully recording other sample data.
This tests the target database's ability to accept new connections as well as handle existing connections.
If the ping process is successful, Foxhound will fill in the Response... Ping column with the ping elapsed time.
Performance Tip:Alert #35 - Separate ping failed may be used to let you know when the target database is
not accepting new connections even though Foxhound remains connected and is successfully gathering sample data.
This is different from Alert #1 - Database unavailable which is only issued when Foxhound itself cannot
connect to the target database to gather a sample or perform Ping-Only sampling.
Include Separate Ping with each lost sample:
Run the ping process one time after failing to gather and record other sample data.
If the ping process also fails (presumably it will), a "Ping also failed" link will be included in the error message. To see more information click on that link:
-- Unable to connect to server 'p001': [SAP][ODBC Driver][SQL Anywhere]Database server not found -- Ping also failed
Ping failed at 10:54:41 AM: SQLCODE -100, SQLSTATE 08W01, Database server not found
connection_string = "DSN=ddd17;AutoStop=NO;AutoStart=NO;ConnectionName=Foxhound-ping-7044;CPOOL=NO"
ping_id = 25828, sampling_id = 8, started_at_sample_set_number = 25827, return_code = -100, diagnostic_code = 1
Include Separate Ping repeatedly during outages:
Run the ping process after repeatedly failing to gather and record other sample data.
If these repeated ping processes fail, Foxhound will update the "Ping failed at..." timestamp shown above.
These Include Separate Ping settings have no effect if Perform Ping-Only Sampling is enabled (see section above).
Ping Connection Name: Set the connection name template for the connections from the Foxhound Ping process to the target database.
This template is used to create the ConnectionName parameter value used by Foxhound's Ping process.
If the template contains the substring nnnn (as in the default Foxhound-ping-nnnn) the nnnn substring
is replaced at runtime by the Windows Process Identifier (PID) of the SQL Anywhere 16 dbsrv16.exe process
that is running the Foxhound database.
This makes it easier to exactly identify where this connection is coming
from when there are a large number of target databases and Foxhound processes running.
button is a context-sensitive link to this Help topic.
This button appears in many locations, each of them a link to a different Help topic in this frame.