help file and technical documentation

Transcription

Hydra
HELP FILE AND TECHNICAL DOCUMENTATION
Warren Sifre and Montrial Harrell
BROADSTROKE CONSULTING INC | INDIANAPOLIS, INDIANA
WWW.BROADSTROKECONSULTING.COM
Hydra
Table of Contents
Introduction to Hydra ........................................................................................................................................................... 5
Requirements ....................................................................................................................................................................... 6
Minimum Requirements ................................................................................................................................................... 6
Supported SQL Server Versions ........................................................................................................................................ 6
Supported Editions ........................................................................................................................................................... 6
Ways to verify SQL Agent is installed and running. ........................................................................................................... 6
How to verify a Database Mail Profile is configured and functional. ................................................................................ 6
Product Overview ................................................................................................................................................................. 7
Hydra’s Monitors .................................................................................................................................................................. 8
Notification Configuration: ............................................................................................................................................... 8
Notification Recipient’s Email ....................................................................................................................................... 8
Notification Recipient’s Text ......................................................................................................................................... 8
Notification Mail Profile ................................................................................................................................................ 8
Disk Space Monitor: .......................................................................................................................................................... 8
Blocked Process Monitor: ................................................................................................................................................. 9
SQL Database Engine Restart Monitor: ............................................................................................................................. 9
Deadlock Monitor: ............................................................................................................................................................ 9
SQL Database Engine Configuration Change Monitor:.................................................................................................... 10
Login Failure Monitor: .................................................................................................................................................... 10
Disk I/O taking longer than 15 seconds Monitor: ........................................................................................................... 10
Potential Drive Failure Monitor: ..................................................................................................................................... 10
SQL Severity 16 – 17 AND 19 – 25 Message Monitor:..................................................................................................... 11
Integrity Check Monitor: ................................................................................................................................................. 11
SQL Agent Long Running Job Monitor: ........................................................................................................................... 11
Alert Filtering: ................................................................................................................................................................. 12
Alert Filtering Architecture ......................................................................................................................................... 12
View existing Alert Filters: .......................................................................................................................................... 13
Adding a new Alert Filter: ........................................................................................................................................... 13
Example of alert filter creation statement: ................................................................................................................. 13
Hydra’s Maintenance .......................................................................................................................................................... 14
1
Hydra
SQL Error Log Cycle: ........................................................................................................................................................ 14
Database Backup History Cleanup: ................................................................................................................................. 14
Hydra Log Cleanup: ......................................................................................................................................................... 14
Update Statistics: ............................................................................................................................................................ 14
Index Maintenance: ........................................................................................................................................................ 15
Database Backups: .......................................................................................................................................................... 15
Default Backup Paradigm:........................................................................................................................................... 15
Recommended Folder Structure for Backup Files: ...................................................................................................... 16
Recommended Backup File Retention: ....................................................................................................................... 16
Restoration Process Details: ....................................................................................................................................... 16
Database Backup Retention Maintenance Plan: ......................................................................................................... 17
Appendix A: Object List ....................................................................................................................................................... 18
SQL Operators................................................................................................................................................................. 18
Hydra Email ................................................................................................................................................................. 18
Hydra Text................................................................................................................................................................... 18
SQL Alerts ....................................................................................................................................................................... 18
Hydra_Alert Severity 16 .............................................................................................................................................. 18
Hydra_Config Change ................................................................................................................................................. 19
Hydra_Deadlock Alert ................................................................................................................................................. 20
Hydra_IO errors .......................................................................................................................................................... 20
Hydra_Login Failures .................................................................................................................................................. 20
Hydra_Potential Drive Failure ..................................................................................................................................... 20
SQL Agent Jobs ............................................................................................................................................................... 20
Hydra_Backup History CleanUp .................................................................................................................................. 20
Hydra_Blocking Notification ....................................................................................................................................... 20
2
Hydra
Hydra_Calculate Job Runtime ..................................................................................................................................... 21
Hydra_Capture Alerts ................................................................................................................................................. 21
Hydra_Clean Up Logs .................................................................................................................................................. 21
Hydra_Cycle Error Log ................................................................................................................................................ 21
Hydra_Database Backup – DIFF .................................................................................................................................. 21
Hydra_Database Backup – FULL.................................................................................................................................. 22
Hydra_Database Backup – LOGS ................................................................................................................................. 22
Hydra_DeadLock Alert Notification ............................................................................................................................ 22
Hydra_Disk Space Check ............................................................................................................................................. 22
Hydra_Index Maintenance.......................................................................................................................................... 22
Hydra_Integrity Check ................................................................................................................................................ 23
Hydra_Long Running Jobs ........................................................................................................................................... 23
Hydra_Restart Notification ......................................................................................................................................... 23
Hydra_Statistics Update ............................................................................................................................................. 23
Hydra Admin Database Tables ........................................................................................................................................ 23
ALRT_Filters ................................................................................................................................................................ 23
ALRT_Log .................................................................................................................................................................... 24
BKU_Log...................................................................................................................................................................... 25
BLK_Log ...................................................................................................................................................................... 25
DLK_Log ...................................................................................................................................................................... 26
ICE_Log ....................................................................................................................................................................... 26
IDX_Log ....................................................................................................................................................................... 26
LRJ_Attribute .............................................................................................................................................................. 27
LRJ_History ................................................................................................................................................................. 27
LRJ_Log ....................................................................................................................................................................... 27
OBJ_TYPE .................................................................................................................................................................... 27
OBJ_VER...................................................................................................................................................................... 28
PRM_LIST .................................................................................................................................................................... 28
UPS_Log ...................................................................................................................................................................... 28
Hydra Admin Database Views ......................................................................................................................................... 29
VW_OBJECT_LIST ........................................................................................................................................................ 29
Hydra Admin Functions................................................................................................................................................... 29
GetDatabase ............................................................................................................................................................... 29
3
Hydra
Hydra Admin Stored Procedures .................................................................................................................................... 29
Hydra_AlertLog ........................................................................................................................................................... 29
Hydra_BackupPathSetup ............................................................................................................................................ 30
Hydra_BlockingNotification ........................................................................................................................................ 30
Hydra_CalcAvgRuntime .............................................................................................................................................. 31
Hydra_CheckForLRJ .................................................................................................................................................... 31
Hydra_CleanUpLogs .................................................................................................................................................... 31
Hydra_CommandExecute ........................................................................................................................................... 32
Hydra_DatabaseBackups ............................................................................................................................................ 32
Hydra_DiskFreeSpaceAlert ......................................................................................................................................... 34
Hydra_HistoryClean .................................................................................................................................................... 34
Hydra_IndexOptimize ................................................................................................................................................. 35
Hydra_IntegrityCheck ................................................................................................................................................. 37
Hydra_RestartNotification .......................................................................................................................................... 38
Hydra_UpdateStats ..................................................................................................................................................... 38
4
Hydra
Introduction to Hydra
Hydra is a collection of native SQL Objects working in concert to provide a very robust monitoring and maintenance
process. The goal of Hydra is to provide visibility into a SQL Server environment without the need of resource
consuming 3rd Party Applications. This is accomplished by not having any CLRs or Windows Agent Services installed on
the SQL Instance and only utilizing Native T-SQL Statements and SQL Agent. A combination of Stored Procedures, SQL
Agent Jobs, SQL Alerts, Functions, Database Tables and SQL Operators are used.
5
Hydra
Requirements
Minimum Requirements



SQL Database Engine ( Per Instance)
SQL Agent Configured and Functional (Per Instance)
o NOTE: Functional SQL Agent is defined as having the SQL Agent service running.
Database Mail Profile Configured and Functional (Per Instance)
Supported SQL Server Versions




SQL 2005 SP 4
SQL 2008 (All SPs)
SQL 2008 R2 (All SPs)
SQL 2012 (All SPs)
o AlwaysOn Availability Groups supported for Backups.
NOTE: The acronym SP represents Service Pack.
Supported Editions

Any Addition having a SQL Agent Service Supported.
Ways to verify SQL Agent is installed and running.


Review whether the SQL Agent Service is running under Windows Services for the instance Hydra is to be
deployed.
Launch SQL Server Management Studio (SSMS), login to the instance and check to see if you see SQL Agent in
the navigation tree with a greenish icon and you are able to expand the node to see the elements within.
How to verify a Database Mail Profile is configured and functional.
1. Launch SQL Server Management Studio (SSMS) and login to the instance Hydra is to be deployed.
2. Expand the Management node and right click on Database Mail.
3. Select “Send Test Email…”
a. If a message is received asking if you want to enable Database Mail, then Database Mail is not
configured.
4. Enter in your email address in the TO: entry box and click the SEND button.
a. If you receive an email in a couple of minutes from the instance, then Database Mail is functional.
b. If you do not receive an email in a couple of minutes, then right click on the Database Mail and select
“View Database Mail Log…” and when it opens, check for errors.
6
Hydra
Product Overview
The following is a list of events Hydra Monitors:











SQL Process Blocking.
SQL Process Deadlocking.
SQL Database Engine Configuration Changes.
SQL Database Engine Restart.
SQL Agent Job executing for a duration longer than normal.
Disk Space Monitor.
SQL Alerts Severity Levels 16-17 and 19 – 25.
Potential Drive Failure.
Login Failures.
Disk I/O taking longer than 15 seconds.
Integrity Checks.
The following is a list of Hydra Maintenance:






Database Backups.
SQL Error Log Cycle.
SQL Database Backup History Clean up.
Index Rebuild/Reconfigure.
Update Statistics.
Hydra Log Clean up.
Hydra performs Maintenance and Monitoring using the following architecture:
NOTE: For a list of all objects in Hydra Admin DB and SQL Agent, please review “Appendix A”.
7
Hydra
Hydra’s Monitors
The intent of the monitors within Hydra is to insure visibility into the SQL Database Engine and its behavior throughout
the day. The variety of alerts and monitors are described in the following section.
Notification Configuration:
All alerts and monitors use email notifications to either deliver to an inbox or as an email-to-text text message to a cell
phone or pager. Hydra has a table named PRM_LIST in Hydra’s Admin DB which contains a variety of records representing
the parameters being passed to Stored Procedures being executed.
Notification Recipient’s Email
To reconfigure the Notification Recipients for normal inbox delivery of notifications, you would execute the following
statement against the Hydra Admin database:
Update PRM_List Set PL_ParamValue = ‘<EmailAddresses>’ Where PL_ParamName = ‘DBA Alerts’
NOTE: Please change the value of <EmailAddresses> to the actual email addresses being configured.
Notification Recipient’s Text
To reconfigure the Notification Recipients for text delivery of notifications, you would execute the following statement
against the Hydra Admin database:
Update PRM_List Set PL_ParamValue = ‘<EmailAddresses>’ Where PL_ParamName = ‘DBA Alerts Text’
NOTE: Please change the value of <EmailAddresses> to the actual email addresses being configured.
Notification Mail Profile
To reconfigure the Notification Process’ Mail Profile in use, you would execute the following statement against the Hydra
Admin database:
Update PRM_List Set PL_ParamValue = ‘<MailProfileName>’ Where PL_ParamName = ‘MailProfile’
NOTE: Please change the value of <MailProfileName> to the actual mail profile being configured.
Disk Space Monitor:
The disk space monitor is a SQL Agent Job named Hydra_Disk Space Check. The purpose of this job is to evaluate the
amount of free space on the drives currently in use by SQL Server and if the amount of free space is less than the amount
configured, an alert is triggered. The alert will send an email message.
When the process runs for the first time, it will create a record for each drive in use by the SQL Server Database Engine
within the PRM_List table with the default value of 5120 (5GB) as the threshold.
8
Hydra
To change the threshold of a specific drive letter, execute the following statement against the Hydra Admin database:
Update PRM_List Set PL_ParamValue = ‘<NewNumberInMB>’ Where PL_ParamName = ‘<DriveLetter>’
NOTE: Please change the value of <NewNumberInMB> to the value in MB whereby the alert will trigger. Please change
the value of <DriveLetter> to the drive letter whose value is to be changed.
IMPORTANT NOTE: Mount Points are not evaluated by this monitor.
Blocked Process Monitor:
The blocked process monitor is a SQL Agent Job named Hydra_Blocking Notification and the process will run for 14
minutes and 15 seconds per execution. The purpose of this job is to detect whether there are processes trying to work
with the same database table or object at the same time, but are not able to do so. When two processes need perform
an action on the same object requiring an Exclusive Lock, the first one to arrive will get access to the object, whilst all
others arriving later will be forced to wait. This condition is aptly named a Blocked Process. Having too many blocked
processes can result in poor performance of the SQL Database Engine. An email message is delivered in the event of a
blocked process as well as a log entry in the BLK_Log table within the Hydra Admin database. In certain environments,
blocked processes are normal and receiving an alert for every occurrence detected would be unnecessary. There is a
parameter in the PRM_List table which controls whether an alert is triggered in the event of a blocked process. The event
of a blocked process will still be logged in the BLK_Log table, but the notification is disabled.
To disable the alert notifications for blocked processes, execute the following statement against the Hydra Admin
database:
Update PRM_List Set PL_ParamValue = ‘0’ Where PL_ParamName = ‘BlockAlertState’
To enable the alert notifications for blocked processes, execute the following statement against the Hydra Admin
database:
Update PRM_List Set PL_ParamValue = ‘1’ Where PL_ParamName = ‘BlockAlertState’
SQL Database Engine Restart Monitor:
The restart monitor will send an email and text messages in the event the SQL Database Engine is restarted. The agent
job named Hydra_Restart Notification will execute upon restart of SQL Agent (which will happen if the related database
engine is restarted). The running of the job does not actually trigger an alert, it just triggers the execution of the job. The
triggering of the alert is performed when checking the creation date of the TempDB to the current date. If the date
difference in days is 0, then the alert is triggered.
Deadlock Monitor:
The deadlock monitor is triggered by a SQL Agent Alert which in turn will execute a SQL Agent Job named Hydra_Deadlock
Alert Notification. The SQL Agent Job will send an email message and log an entry in the DLK_Log table within the Hydra
Admin database. The Alert is configured to check the Deadlock/Sec counter within performance monitor to determine if
9
Hydra
a deadlock has occurred. Deadlocks occur when there are two distinct transactions running and each one has a resource
the other one needs to complete. Since they both are holding each other hostage, the SQL Database Engine will determine
which one is the least expensive process to roll back and declare that process as the deadlock victim. Having too many
deadlocks can cause performance issues.
SQL Database Engine Configuration Change Monitor:
The configuration change monitor is triggered by a SQL Agent Alert which in turn will execute a SQL Agent Job named
Hydra_Capture Alerts. The Alert is configured to be triggered by any configuration change event having been captured.
These events are detected by the Alert and the pertinent information is sent as an email message and log an entry in the
ALRT_Log table with the Hydra Admin database. Certain applications or processes may perform this activity quite
frequently, there is an alert filtering component which this alert adheres. (Please see “Alert Filtering” section for more
information)
Login Failure Monitor:
The login failure monitor is triggered by a SQL Agent Alert which in turn will execute a SQL Agent Job named
Hydra_Capture Alerts. The Alert is configured to be triggered by any login failure event has been captured. These events
are detected by the Alert and the pertinent information is sent as an email message and log an entry in the ALRT_Log table
with the Hydra Admin database. Certain applications or processes may cause this activity quite frequently for a variety of
reasons, there is an alert filtering component which this alert adheres. (Please see “Alert Filtering” section for more
information)
Disk I/O taking longer than 15 seconds Monitor:
This monitor is triggered by a SQL Agent Alert which in turn will execute a SQL Agent Job named Hydra_Capture Alerts.
The Alert is configured to be triggered by any disk I/O request has taken longer than 15 seconds to service event has been
captured. These events are detected by the Alert and the pertinent information is sent as an email message and log an
entry in the ALRT_Log table with the Hydra Admin database. Certain environments may cause this activity quite frequently
for a variety of reasons, there is an alert filtering component which this alert adheres. (Please see “Alert Filtering” section
for more information)
Potential Drive Failure Monitor:
The potential drive failure monitor is triggered by a SQL Agent Alert which in turn will execute a SQL Agent Job named
Hydra_Capture Alerts. The Alert is configured to be triggered by any potential drive failure event has been captured.
These events are detected by the Alert and the pertinent information is sent as an email message and log an entry in the
ALRT_Log table with the Hydra Admin database. Certain applications or processes may cause this activity quite frequently
for a variety of reasons, so as there is an alert filtering component which this alert adheres. (Please see “Alert Filtering”
section for more information)
10
Hydra
SQL Severity 16 – 17 AND 19 – 25 Message Monitor:
The SQL Severity 16 – 17 AND 19 -25 monitors are triggered by a SQL Agent Alert, one for each specific severity number,
which in turn will execute a SQL Agent Job named Hydra_Capture Alerts. The Alerts are configured to be triggered by any
of these events have been captured. These events are detected by the Alert and the pertinent information is sent as an
email message and log an entry in the ALRT_Log table with the Hydra Admin database. Certain applications or processes
may cause this activity quite frequently for a variety of reasons, so as there is an alert filtering component which this alert
adheres. (Please see “Alert Filtering” section for more information)
Integrity Check Monitor:
The integrity check monitor is a SQL Agent job named Hydra_Integrity Check which executes a stored procedure at a given
interval. The default interval of execution is nightly. The intent of this monitor is to check the physical and logical integrity
of each database and report back any errors discovered, which if left ignored can lead to corrupt data or even an entire
database corruption. Every execution of an integrity check for each database is logged into a table named ICE_Log within
the Hydra Admin database. The intent of the log is to allow for duration trending across multiple executions and even
count the number of times errors occur. In the event of there being errors reported by the Integrity Check an email
notification is sent and a special log entry is added for the database with error message in the ICE_Log table within the
Hydra Admin database. This monitor has several parameters to help mitigate certain situations. The parameters can be
viewed in “Appendix A -> Hydra Admin Stored Procedures - Hydra_IntegrityCheck”.
The execution configurations the parameters offer are:



If too many databases for the integrity check to complete nightly, then you can configure the integrity check
monitor to execute in an Odd/Even interval. This ensures all databases have an integrity check, but instead of
having ALL databases executed each night, only databases with an even number Database ID will execute on one
night, and the alternate night will execute databases with an odd number Database ID.
If there are certain databases being too large to run under normal nightly executions, you can set a size pivot
threshold to the number of MBs to become the threshold for when the database is too large for a normal integrity
check and instead perform a Physical_Only integrity check. Physical_Only integrity checks take less time, but are
not as thorough in its check. You will also want to set what day of the week you wish the size pivot threshold is
to be ignored and a full integrity check be performed.
If odd/even and pivot thresholds are configured, you can set the day the size pivot threshold is ignored for odd
and even individually. Meaning you can perform the full integrity check on even numbered Database IDs on a
different day than when the full integrity check is performed on the odd numbered Database IDs.
SQL Agent Long Running Job Monitor:
The long running job monitor is a process having two distinct SQL Agent jobs executing in concert to accomplish this
monitor.


Hydra_Calculate Runtime
Hydra_Long Running Jobs
11
Hydra
The Hydra_Calculate Runtime job, when executed looks for new jobs having been added to SQL Agent and calculates the
average runtime for each. The job assigns a runtime threshold of ‘2’ and stores the info in a table. The job executes once
a week, by default on Sunday.
The Hydra_Long Running Jobs job, when executed looks at the MSDB logs to see what SQL Agent Jobs are currently being
executed. It calculates when the SQL Agent Jobs started their process and how long they have been executing at time of
check. The derived duration is then compared against the threshold calculated by Hydra_Calculate Runtime job and if
the process is running longer than the threshold an email alert is generated and a log entry is made into the LRJ_Log table
within the Hydra Admin database.
The monitor has multiple levels of notifications to help insure only the critical jobs send Text Messages, semi-critical jobs
send only email and jobs whose execution does not have a business impact does not send any messages when they run
longer than expected. By default, all jobs added will be set to send only emails. Within the long running job email are
instructions for how to change the notification methods.
Alert Filtering:
The concept of alert filtering came about when the desire for visibility was being undermined by the lack of resources to
address the issues being reported. The term noise was coined as a way to describe alerts being triggered of which no
action can be taken. As a way to filter out the noise and insure alerts received by the DBA are actionable, the alert filter
was created.
Alert Filtering Architecture
When an alert is triggered, the alert executes an Agent Job and sends the alert details in the form of SQL Agent Tokens.
The agent job executes a stored procedure which contacts the Hydra Admin database, inserts a record into the ALRT_Log
table for historical trending and then determines if this alert has been designated as filtered to either send an email or
not. The diagram below helps articulate what happens with alert filtering.
12
Hydra
View existing Alert Filters:
To view alert filters configured, execute the following statement against the Hydra Admin database:
Select * from ALRT_Filters
Results:
NOTE: For table definition, please review “Appendix A -> Hydra Admin Database Tables -> ALRT_Filter”.
NOTE: Only records having an AF_Enabled = 1 are actually active filters. All others exist, but are ignored.
Adding a new Alert Filter:
To add a new alert filter, you need to execute the statement below:
INSERT [dbo].[ALRT_Filters] (AF_Error, AF_Severity, AF_MSG_Contains, AF_Enabled, AF_DateCreated, AF_CreatedBy,
AF_Description)
SELECT <ErrorMessageId>, <ErrorMessageSeverity>, ‘<CriteriaToFilterBy>’, <EnabledOrDisabled>,
‘<DateCreated>’, SUSER_NAME(), ‘<FilterDescription>’
NOTE: Please change <ErrorMessageID> to the error message id, <ErrorMessageSeverity> to the error message severity
displayed in either the email alert or the SQL error log.
NOTE: Please change <CriteriaToFilterBy> to the WHERE Clause statement for filtering. There are only two parameters
that can be used as criteria, @message and @time. The @message is the actual message being returned by the alert. The
@time is the time being returned by the alert. The use of normal WHERE Clause operators are valid. Please see notice
example below or query the ALRT_Filters table for more examples.
Example of alert filter creation statement:
INSERT [dbo].[ALRT_Filters] (AF_Error, AF_Severity, AF_MSG_Contains, AF_Enabled, AF_DateCreated, AF_CreatedBy,
AF_Description)
SELECT 15457, 10, '@message like ''%show advanced options%''', 1, '02-04-2013', SUSER_NAME(), 'This will
elminate the Show Advance Options notifications'
NOTE: If alert filter is not working, please verify the following values match the alert being filtered, AF_Error, AR_Severity,
AF_MSG_Contains and AF_Enabled = 1. If these do not match the actual alert message being filtered, the filter will not
work.
13
Hydra
Hydra’s Maintenance
The intent of the maintenance within Hydra is to promote Performance and Data Recovery Best Practices are being
executed against the SQL Database Engine and the Databases within. There is a variety of processes within Hydra created
specifically for this purpose. This section we will detail out the distinct maintenance process and any related features and
options.
SQL Error Log Cycle:
The SQL Error Log Cycle is a SQL Agent Job named Hydra_Cycle Error Log which executes a system stored procedure. SQL
Error logs can grow over time and if left to its own devices it will continue to grow to a very large size. A very large error
log can cause the environment to incur some overhead in the ability to read and insert entries into the log. Plus the drive
space consumed by logs that are allowed to grow indefinitely. The SQL Error Log Cycle process will restart the Error Log
as if the instance had restarted, thus allowing for a one-to-one alignment between error logs and the contents within
being for one day.
Database Backup History Cleanup:
The Database Backup History Cleanup is a SQL Agent Job named Hydra_Backup History Cleanup which executes a Stored
Procedure. The purpose of this job is to delete all MSDB database backup log information about databases no long existing
on the instance. Without this process, the Database Backup process may incur a performance impact if the MSDB
database backup log has too many records.
Hydra Log Cleanup:
Many of the processes within Hydra have logging for trending and investigation activities. These logs can start to add up
after a while, especially the processes executing in short intervals or generating a lot of entries per execution. This process
is kicked off by a SQL Agent Job named Hydra_Clean Up Logs. This process will clean up the following tables of records
older than a specified time. Please refer to “Appendix A -> SQL Agent Jobs -> Hydra_Clean Up Logs” for more details.







BKU_Log
BLK_Log
DLK_Log
IDX_Log
ICE_Log
LRJ_Log
UPS_Log
Update Statistics:
Update Statistics is a SQL Agent Job named Hydra_Statistics Update. This process will help maintain the existing statistics
in each database. Only when statistics are out of date or stale will action be taken to update. There are a variety of
14
Hydra
parameters for this process which have been outlined in “Appendix A -> Hydra Admin Database Stored Procedures ->
Hydra_UpdateStats”.
Index Maintenance:
Index Maintenance is a SQL Agent Job named Hydra_Index Maintenance. This process will evaluate the state of existing
indexes and determine whether a Rebuild, Reorganization or no action is taken. There are a variety of parameters for this
process which have been outlined in the “Appendix A -> Hydra Admin Database Stored Procedures ->
Hydra_IndexOptimize”.
Database Backups:
Database Backups are the cornerstone of any useful recovery strategy. Hydra can perform the three most widely used
backup types; Full, Differentials and Transaction Logs. There are a variety of parameters for this process which have been
outlined in the “Appendix A -> Hydra Admin Database Stored Procedures -> Hydra_DatabaseBackup”.



FULL Backup – A complete backup of the database. This is essentially a snapshot of what the database contents
are at time of backup. In most circumstances FULL Backups would be performed once a week as a way to keep
conserve disk space. Without compression these backups can be as large as the actual database itself.
DIFFERENTIAL Backup – A partial backup of what has changed in the database since last FULL Backup. In most
circumstances DIFFERENTIAL Backups would be performed every night, except the night the FULL Backup is taking
place. These files will only be as big as the amount of data change in the database. Typically these files are much
smaller in size than FULL Backups.
TRANSACTION LOG Backup – An incremental backup capturing what has changes since either the last FULL
Backup, last Differential Backup or last Transaction Log Backup. TRANSACTION LOG Backups are typically
performed in a very frequent intervals (15, 30, 60 minutes) and are intended to allow for point-in-time restoration.
These files are typically very small, depending on the amount of change in the database since the last backup.
Default Backup Paradigm:
Hydra will schedule the backups in the following manner (if no changes are made from the default):
15
Hydra
Recommended Folder Structure for Backup Files:
We recommend once a location has been identified for SQL Backups, the following folder
structure is created in the desired location. In the illustration on the right, the
SQLBackups2 folder is the location we want our backups to arrive. The other
folders/subfolders should be created.
Recommended Backup File Retention:
One key component Hydra does not address (purposely) is the retention of these backup files. Retention schedules
should align with business requirements for disaster recovery and/or government compliance. The suggested retention
schedule for the various backups types are:



FULL Backups – 14 Days (total of 2 files)
DIFFERENTIAL Backups – 7 Days (6 files)
TRANSACTION LOG Backups – 3 Days (file count will vary on interval of execution)
This Retention Schedule will ensure you can restore your database at any point in time within the most recent 72 hours,
or restore your database to a nightly backup for the last 7 days.
Restoration Process Details:
In the event of a database restoration, there is a specific order these files must be restored.
Let us walk through a scenario for restoration assuming the backup paradigm for the organization is using Hydra’s default.
The organization discovered Thursday morning data is missing from a database named “HelpMe”. After some
investigation the decision is made to restore the database to the point-in-time of the day before (Wednesday) to 3:15PM.
To restore the “HelpMe” database to this point we would need to perform the following steps in order.
1. Restore the FULL Backup from the Sunday Backup, with the clause of No_Recovery.
a. This will restore the database to Sunday 11PM state.
b. The required Full backup for the Differential and Transaction Log backups will have been restored.
c. The No_Recovery clause will maintain the database in a state allow for additional backup files to be
restored.
16
Hydra
i. NOTE: If this is not performed, the restoration of the Differential and Transaction Log files will fail.
2. Restore the Differential Backup from the Tuesday Backup with the clause of No_Recovery.
a. This will restore the database to Tuesday 11PM state.
b. The No_Recovery clause will maintain the database in a state allow for additional backup files to be
restored.
3. Restore each Transaction Log backup starting with the Wednesday 12AM through to Wednesday 3PM with the
clause of No_Recovery.
a. This will restore the database to Wednesday 3PM state.
b. The Transaction Log backups must be restored in the order they were taken.
c. The No_Recovery clause will maintain the database in a state allow for additional backup files to be
restored.
4. Restored the Transaction Log backup file for Wednesday 4PM, but configure it to stop at 3:15PM and with
Recovery.
a. This will restore the database to Wednesday 3:15PM.
b. The Recovery clause will complete the restoration of the database and allow the database to be accessible
by applications and users.
Database Backup Retention Maintenance Plan:
With the Database Backup Job deployment of Hydra, the next thing required is the creation of a Maintenance plan to
delete the database backup files exceeding the duration outlined in the organization’s retention schedule. For complete
instructions on creating a maintenance plan based on the suggested retention schedule, please visit
http://www.broadstrokeconsulting.com/create-a-database-backup-cleanup-maintenance-plan/.
17
Hydra
Appendix A: Object List
SQL Operators
Hydra Email
This is used to send an email about failed SQL Agent Jobs. All Hydra SQL Agent Jobs are configured to send email
notifications of failures using this operator.
Hydra Text
This is used to send a Text Message about failed SQL Agent Jobs. Only Agent Jobs with high impact in the event of a failure
would be configured to use this operator.
SQL Alerts
Hydra_Alert Severity 16
This is triggered when a severity 16 error occurs on the Instance. Severity 16 errors are typical end user generated errors,
but can also be generated by automated processes. This alert will trigger a SQL Agent job named Hydra_Capture Alerts
(See SQL Agent Job section for details). This alert is configured by default to only send emails to addresses configured in
the record for 'DBA Alerts' within the PRM_List table.
This is triggered when a severity 17 error occurs on the Instance. Severity 17 errors are "Insufficient Resources" errors.
This alert will trigger a SQL Agent job named Hydra_Capture Alerts (See SQL Agent Job section for details). This alert is
configured by default to only send emails to addresses configured in the record for 'DBA Alerts' within the PRM_List table.
This is triggered when a severity 19 error occurs on the Instance. Severity 19 errors are "SQL Server Error in Resource"
errors. This alert will trigger a SQL Agent job named Hydra_Capture Alerts (See SQL Agent Job section for details). This
alert is configured by default to send emails to addresses configured in the record for 'DBA Alerts' within the PRM_List
table. This alert is also configured to send text messages to by way of emails to addresses configured in the record for
'DBA Text Alerts' within the PRM_List table.
This is triggered when a severity 20 error occurs on the Instance. Severity 20 errors are "SQL Server Fatal Error in Current
Process" errors. This alert will trigger a SQL Agent job named Hydra_Capture Alerts (See SQL Agent Job section for details).
This alert is configured by default to send emails to addresses configured in the record for 'DBA Alerts' within the PRM_List
table. This alert is also configured to send text messages to by way of emails to addresses configured in the record for
'DBA Text Alerts' within the PRM_List table.
18
Hydra
This is triggered when a severity 21 error occurs on the Instance. Severity 21 errors are "SQL Server Fatal Error in Database
(dbid) Processes" errors. This alert will trigger a SQL Agent job named Hydra_Capture Alerts (See SQL Agent Job section
for details). This alert is configured by default to send emails to addresses configured in the record for 'DBA Alerts' within
the PRM_List table. This alert is also configured to send text messages to by way of emails to addresses configured in the
record for 'DBA Text Alerts' within the PRM_List table.
This is triggered when a severity 22 error occurs on the Instance. Severity 22 errors are "SQL Server Fatal Error Table
Integrity Suspect" errors. This alert will trigger a SQL Agent job named Hydra_Capture Alerts (See SQL Agent Job section
This is triggered when a severity 23 error occurs on the Instance. Severity 23 errors are "SQL Server Fatal Error: Database
Integrity Suspect" errors. This alert will trigger a SQL Agent job named Hydra_Capture Alerts (See SQL Agent Job section
This is triggered when a severity 24 error occurs on the Instance. Severity 24 errors are "Hardware Error" errors. This alert
will trigger a SQL Agent job named Hydra_Capture Alerts (See SQL Agent Job section for details). This alert is configured
by default to send emails to addresses configured in the record for 'DBA Alerts' within the PRM_List table. This alert is
also configured to send text messages to by way of emails to addresses configured in the record for 'DBA Text Alerts'
within the PRM_List table.
This is triggered when a severity 25 error occurs on the Instance. Severity 25 errors are "Hardware Error" errors. This alert
will trigger a SQL Agent job named Hydra_Capture Alerts (See SQL Agent Job section for details). This alert is configured
by default to send emails to addresses configured in the record for 'DBA Alerts' within the PRM_List table. This alert is
also configured to send text messages to by way of emails to addresses configured in the record for 'DBA Text Alerts'
within the PRM_List table.
Hydra_Config Change
This is triggered when an error message number of 15457 occur on the Instance. Error message number 15457 are
informational messages stating that someone or some process has changed SQL Server Instance configuration setting.
This alert will trigger a SQL Agent job named Hydra_Capture Alerts (See SQL Agent Job section for details). This alert is
configured by default to only send emails to addresses configured in the record for 'DBA Alerts' within the PRM_List table.
19
Hydra
Hydra_Deadlock Alert
This is triggered when the performance monitor counter named "Number of Deadlocks / sec" is greater than 0. This is an
informational notification stating that deadlocks are occurring on the SQL Server Instance. This alert will trigger a SQL
Agent job named Hydra_Capture Alerts (See SQL Agent Job section for details). This alert is configured by default to only
send emails to addresses configured in the record for 'DBA Alerts' within the PRM_List table.
Hydra_IO errors
This is triggered when an error message number of 833 occurs on the Instance. Error message number 833 is informational
messages stating specific IO requests are taking longer than 15 seconds to complete. This alert will trigger a SQL Agent
job named Hydra_Capture Alerts (See SQL Agent Job section for details). This alert is configured by default to only send
emails to addresses configured in the record for 'DBA Alerts' within the PRM_List table.
Hydra_Login Failures
This is triggered when an error message number of 18456 occur on the Instance. Error message number 18456 are
informational messages stating that someone or some process has failed to successfully login to SQL Server Instance. This
can be a sign of a potential hacker attack or an orphaned process. This alert will trigger a SQL Agent job named
Hydra_Capture Alerts (See SQL Agent Job section for details). This alert is configured by default to only send emails to
addresses configured in the record for 'DBA Alerts' within the PRM_List table.
Hydra_Potential Drive Failure
This is triggered when an error message number of 825 occur on the Instance. Error message number 825 errors are readretry events which is a sign of impending disk failure. This alert will trigger a SQL Agent job named Hydra_Capture Alerts
(See SQL Agent Job section for details). This alert is configured by default to send emails to addresses configured in the
record for 'DBA Alerts' within the PRM_List table. This alert is also configured to send text messages to by way of emails
to addresses configured in the record for 'DBA Text Alerts' within the PRM_List table.
SQL Agent Jobs
Hydra_Backup History CleanUp



Description: Clear out backup history to ensure the backup process is as performance friendly as possible. Too
many backup history records can cause the insertion of backup history to be slow, thus causing the backups
themselves to slow down.
Schedule: Weekly, Every Sunday at 12:30AM
Step 1: EXEC [Hydra_Admin].[dbo].[Hydra_HistoryClean]
Hydra_Blocking Notification



Description: Notify during Blocking Events that exceed the Blocked Process Threshold.
Schedule: Every 15 minutes every day
Step 1: EXEC [Hydra_Admin].[dbo].[Hydra_BlockingNotification]
20
Hydra
Hydra_Calculate Job Runtime



Description: Looks for new jobs that have been added and calculates the average runtime for each. Assigns a
runtime threshold and stores the info in a table.
Schedule: Weekly, Every Sunday are 12:00AM
Step 1: EXEC [Hydra_Admin].[dbo].[Hydra_CalcAvgRuntime]
Hydra_Capture Alerts



Description: Captures all Alerts triggered on the server to allow for alert notification filtering.
Schedule: None – Alert Triggered
Step 1: EXEC [Hydra_Admin].[dbo].[Hydra_Alertlog] '$(ESCAPE_SQUOTE(A-DBN))', '$(ESCAPE_SQUOTE(A-SVR))',
'$(ESCAPE_SQUOTE(STRTDT))', '$(ESCAPE_SQUOTE(STRTTM))', '$(ESCAPE_SQUOTE(A-SEV))',
'$(ESCAPE_SQUOTE(A-ERR))', '$(ESCAPE_SQUOTE(A-MSG))'
Hydra_Clean Up Logs









Description: Clean up log entries of the different log tables supported by Hydra. Parameters for
Hydra_CleanUpLogs are NumberOfMonths and LogTableAffected. NumberOfMonth is the age in months old to
delete records. LogTableAffected allows you to choose the retention of each individual log table. 1 = Backup Logs
(BKU_Log), 2 = Blocking Logs (BLK_Log), 3 = Deadlock Logs (DLK_Log), 4 = Index Maintenance Logs (IDX_Log), 5 =
Update Statistics Logs (UPS_Log), 6 = Integrity Check Execution Logs (ICE_Log), 7 = Long Running Job Event Logs
(LRJ_Log). Parameters for Hydra_CleanUpWaitStats are NumberOfDaysToKeepHourlyStats (clean up WTS_Hour),
NumberOfDaysToKeepDailyStats (clean up WTS_Day), NumberOfMonthsToKeepWeeklyStats (clean up
WTS_Week), NumberOfMonthsToKeepMonthlyStats (clean up WTS_Month).
Schedule: Every day at 12:00AM
Step 1: EXEC [Hydra_Admin].[dbo].[Hydra_CleanUpLogs] -1, 1
Hydra_Cycle Error Log



Description: Creates a new SQL Error Log to ensure we do not have too much information in one log, thus
complicating the location of current events. This affects the SQL Error Log.
Step 1: EXEC [sp_cycle_errorlog]
Hydra_Database Backup – DIFF



Description: Performs a Differential Backup of all databases using the parameters provided.
Schedule: Every Day except Sundays at 11:00PM.
Step 1: EXEC Hydra_Admin.dbo.Hydra_DatabaseBackups 'DIFF', 'E:\SQL_Backups2\Diff', 'E:\SQL_Backups2\Diff',
2, 1, 0, 'ALL DATABASES', 0, $(ESCAPE_SQUOTE(JOBID))
21
Hydra
o
o
NOTE: This job is DISABLED by default.
NOTE: This job will need the Primary and Alternate Backup Paths configured before execution.
Hydra_Database Backup – FULL



Description: Performs a FULL Backup of all databases using the parameters provided.
Schedule: Sundays at 11:00PM.
Step 1: EXEC Hydra_Admin.dbo.Hydra_DatabaseBackups 'FULL', 'E:\SQL_Backups2\Full', 'E:\SQL_Backups2\Full',
2, 1, 0, 'ALL DATABASES', 0, $(ESCAPE_SQUOTE(JOBID))
o NOTE: This job is DISABLED by default.
o NOTE: This job will need the Primary and Alternate Backup Paths configured before execution.
Hydra_Database Backup – LOGS



Description: Performs a Transaction Log Backup of all databases with appropriate Recovery Model using the
parameters provided.
Schedule: Every 1 between the times of 12:00AM and 10:59PM.
o NOTE: The time frame is to prevent backup concurrency issues between FULL/DIFF and Logs.
Step 1: EXEC Hydra_Admin.dbo.Hydra_DatabaseBackups 'LOGS', 'E:\SQL_Backups2\Logs',
'E:\SQL_Backups2\Logs', 2, 1, 0, 'ALL DATABASES', 0, $(ESCAPE_SQUOTE(JOBID))
o NOTE: This job is DISABLED by default.
o NOTE: This job will need the Primary and Alternate Backup Paths configured before execution.
Hydra_DeadLock Alert Notification



Description: Notifies in the event of a Deadlock. This information is recorded and loaded into a table for counts
in the DHR.
Schedule: None – Alert Triggered
Step 1: EXEC [Hydra_Admin].[dbo].[Hydra_Deadlocklog] '$(ESCAPE_SQUOTE(A-DBN))', '$(ESCAPE_SQUOTE(ASVR))', '$(ESCAPE_SQUOTE(STRTDT))', '$(ESCAPE_SQUOTE(STRTTM))', '$(ESCAPE_SQUOTE(A-SEV))',
'$(ESCAPE_SQUOTE(A-ERR))', '$(ESCAPE_SQUOTE(A-MSG))', 1
Hydra_Disk Space Check



Description: Monitors the Disk Free Space available for all disks in use by SQL Server. An email alert is generated
if the values exceed the threshold set.
Schedule: Every 1 hour every day
Step 1: EXEC [Hydra_Admin].[dbo].[Hydra_DiskFreeSpaceAlert]
Hydra_Index Maintenance



Description: Performed Index Maintenance. Based on the options entered, this process will use the percent of
fragmentation to determine if an Index Rebuild or an Index Reogranization will be performed.
Step 1: EXEC [Hydra_Admin].[dbo].[Hydra_IndexOptimize] @Databases = 'USER_DATABASES',
@FragmentationHigh_LOB = 'INDEX_REBUILD_OFFLINE', @FragmentationHigh_NonLOB =
22
Hydra
'INDEX_REBUILD_OFFLINE', @FragmentationMedium_LOB = 'INDEX_REORGANIZE_STATISTICS_UPDATE',
@FragmentationMedium_NonLOB = 'INDEX_REORGANIZE_STATISTICS_UPDATE', @FragmentationLow_LOB =
'NOTHING', @FragmentationLow_NonLOB = 'NOTHING', @FragmentationLevel1 = 5, @FragmentationLevel2 =
30, @PageCountLevel = 1000, @FillFactor = 90, @StatisticsSample = 100, @TimeLimit = 3600, @Execute = 'Y'
Hydra_Integrity Check



Description: Inspect each Database to determine if there are any page allocation errors in logical or physical
structure. There is parameter of RunType. 1 = All Databases, 2 = Odd/Even configuration.
Step 1: EXEC [Hydra_Admin].[dbo].[Hydra_IntegrityCheck] 1
Hydra_Long Running Jobs



Description: Determine if any SQL Agent Job running is taking longer than expected.
Schedule: Every 30 minutes every day
Step 1: EXEC [Hydra_Admin].[dbo].[Hydra_CheckForLRJ]
Hydra_Restart Notification



Description: SQL Server Restart Notification via email and text.
Schedule: None – Triggered when SQL Agent start up
Step 1: EXEC [Hydra_Admin].[dbo].[Hydra_RestartNotification]
Hydra_Statistics Update



Description: Performs an update of all Statistics using the parameters provided.
Step 1: EXEC [Hydra_Admin].[dbo].[Hydra_UpdateStats] @Databases = 'USER_DATABASES',
@StatisticsUpdateOlderThanDays = 7, @StatisticsSampleSize = 100, @TimeLimit = 3600, @Execute = 'y'
Hydra Admin Database Tables
ALRT_Filters


Description: This stores all of the Alert Filters in use by Hydra to help control the spamming of emails and/or text
messages.
Columns:
o AF_ID – ID Column for Alert Filters
o AF_Error – The message number for the error message. (i.e. 825)
 Must be included in a record for the filter to be functional.
o AF_Severity – The severity number for the error message. (i.e. 19)
o AF_MSG_Contains – Stores the WHERE clause component for the filtering of alerts.
 Column value is optional.
23
Hydra


Sample Syntax:
 ‘@message Like ‘’%username%’’’
 ‘@message = ‘’Terry’’’
 ‘@message Like ‘’%monty%’’ and @message Like ‘’%192.168.2.123%’’’
 As long syntax of the column entry matches what would normally follow a WHERE statement, it
will work.
o AF_Enabled – Controls whether the alert filter is enabled for use.
 Data type is BIT.
 Default value is 1/True.
o AF_DateCreated – Stores when the filter was created
 Default value of GetDate() function.
o AF_CreatedBy – Stores who created the filter
 No default value.
o AF_Description – Stores a description of the reason for the filter
 No default value.
o AF_ExpirationDate – Stores a date time value of when an enabled filter can be ignored.
 Default value is ‘12/31/2029’
 If the value is in the past, the filter will be ignored, regardless of whether the filter is enabled or
not.
Additional Info:
o There is 1 default filter enabled upon deployment.
 Filters out “Show Advanced Options” configuration option changes.
ALRT_Log



Description: Stores all of the alerts captured on the instance.
Columns:
o AL_ID – ID Column for alerts logged.
o Database – Name of the database the alert is referencing.
o Server – Name of the Server Instance name the alert is referencing.
o Date – Date of the alert occurrence.
o Time – Time of the alert occurrence.
o Severity – Severity of the alert occurrence.
o Error – Error message number of the alert occurrence.
o Message – The actual message of the alert occurrence.
Additional Info:
o The cleanup of these logs is controlled by the SQL Agent job named ‘Hydra_Clean Up Logs’.
24
Hydra
BKU_Log



Description: Stores information about backups that failed.
Columns:
o BKU_ID – ID column for backups logged.
o DBName – Name of the database whereby a backup failed.
o DateRun – Execution date and time of the failed backup.
o CommandExecuted – The exact command executed which failed in the failed backup.
o RetryCount – The retry number the failed backup occurred.
o Status – Determined whether the specific execution failed or succeeded, and whether it was using primary
or alternate file path.
 0 (zero) = Failed Backup to Primary Path.
 1 (one) = Successful Backup to Primary Path.
 2 (two) = Successful Backup to Alternate Path.
 3 (three) = Failed Backup to Alternate Path.
o Duration – Stores the number of minutes a specific backup execution.
o Size_KB – Stores the size of a specific backup execution in Kilobytes.
o Backup_Type – Indicates the type of backup performed.
 1 (one) = Full Backup
 2 (two) = Transaction Log Backup
 3 (three) = Differential Backup
Additional Info:
BLK_Log


Description: Stores information about blocked processes.
Columns:
o Tstamp – Time the blocked process was recorded.
o SPID – SPID of the process being evaluated.
o Blocked – SPID of the process being blocked.
o Waittype – Result of the type of wait the block is being caused.
o Waittime – The time in seconds the process is blocked.
o Physical_io – The cumulative reads and writes of disk I/O generated by the process.
o Memusage – The number of pages in the procedure cache that are currently allocated to process.
o Cpu_in_seconds – The cumulative CPU time in seconds.
o Name – The name of the database the process is running against.
o Open_tran – The number of transactions open for process.
o Status – The status of the process as time of capture.
o HostName – Name of machine executing the process.
o Program_Name – Name of the application program.
o Cmd – The command currently executed
o Nt_domain – Windows Domain for the client machine.
o Nt_username – Windows users name for the process, if using Windows Authentication.
o Loginname – Login name.
25
Hydra
o
o
o

EventType – Display whether this is a RPC Event or Language Event.
Parameters – Displays either the text being executed or parameters.
EventInfo – Displays either Stored Procedure name if RPC Event or the first 4000 characters of Language
values if Language Event.
o Text – SQL Text being executed.
Additional Info:
DLK_Log



Description: Stores deadlock events in a table.
Columns:
o DL_ID – ID Column for deadlocks logged.
o Database – Name of the database
o Server – Name of the SQL Server Instance
o Date – Date of occurrence of alert.
o Time – Time of occurrence of alert.
o Severity – Severity of the alert.
o Error – Error message number of the alert.
o Message – Error message contents of the alert.
Additional Info:
o Date column stores the value in an integer data type using mmddyy format.
ICE_Log


Description: Stores the execution information for Integrity Checks.
Columns:
o ID – ID Column for ICE records.
o DBName – Name of database integrity check ran on.
o DateRun – Date and time of integrity check execution.
o Duration_Min – Stores the number of minutes the integrity check ran for.
o Outcome – Stores the status of whether the integrity check was successful or failed.
o ErrorMSG – Stores the error message returned by the integrity check.
IDX_Log


Description: Stores the logging information for Indexes having been maintained.
Columns:
o IDX_ID – ID Column for IDX records.
o DBName – Name of the database whose indexes are being maintained.
o DateRun – Date and time of the index maintenance execution.
o DBInfo – Stores the information related to the database.
o IndexName – Name of the index being maintained.
o IndexInfo – Stores the information related to the index.
26
Hydra
o
o

ActionTaken – Stores the command executed for the index.
Parent_IDX_ID – Stores the IDX_ID as a way to determine all the indexes maintained for a specific database
on a specific fun.
Additional Info:
LRJ_Attribute


Description: Stores the thresholds for each Agent Job recognized by the instance.
Columns:
o ID – ID Column for the record.
o JobID – GUID of the Job.
o ImportanceID – Value to help determine if just an email or a text message should be delivered because of
a long running job.
o isEnabled – Determines whether the threshold will be considered for evaluation.
o AvgRunTime – Stores a value in minutes representing the average run time for the specific agent job.
o RunTimeThreshold – Stores a value in minutes representing the calculated runtime threshold for the
specific agent job.
o LastUpdate – Stores a value representing when the last time this record was updated.
o UpdatedBy – Stores a name of who updated these values.
LRJ_History


Description: Stores historical records of LRJ_Attribute records. As records are updated each week in the
LRJ_Attribute table, the original values prior to updates are recorded in the LRJ_History.
Columns:
o JobID – GUID of the job.
o RuntimeThreshold – Stores a value in minutes representing the calculated runtime threshold for the
specific agent job.
o AvgRunTime – Stores a value in minutes representing the average run time for the specific agent job.
o LastUpdated – Stores the value of when the record was inserted into the table.
LRJ_Log


Description: Stores a log of all events triggered by the Long Running Job monitor.
Columns:
o EventDate – Date the event occurred.
o JobName – Name of the SQL Agent Job.
o JobID – GUID of the SQL Agent Job.
o Message – The body of the email message.
OBJ_TYPE


Description: Stores the object types for the OBJ_VER table.
Columns:
27
Hydra
o
o
OT_ID – ID column for record.
OT_Name – Name of the object type.
OBJ_VER


Description: Stores the version for each object in the Hydra_Admin database.
Columns:
o OV_ID – ID column for record.
o OV_OT_ID – Stored the ID for the object type.
o OV_Name – Named of the object.
o OV_Version – Version number of the object.
o OV_DateCreated – Date the object was created.
o OV_Description – Role or Purpose of the object.
o OV_Mismatch – A flag to indicate whether the version reported by the table is not the version actually in
the database.
PRM_LIST


Description: Stored Parameters in use by Stored Procedures support profiles.
Columns:
o PL_ID – Id Column for the record.
o PL_Scope – Name of the Profile for the specific parameter.
o PL_ParamName – Name of the Parameter.
o PL_ParamValue – Value of the Parameter.
o PL_LastModified – Date and Time of when the parameter was added.
o PL_LastModifiedBy – Name of the user adding the parameter.
o PL_Description – A description of what the parameter represents.
UPS_Log



Description: Stores the logging information for Statistics having been updated.
Columns:
o UPS_ID – ID Column for the record.
o DBName – Name of the database.
o DateRun – Date and Time of when the command was executed.
o DBInfo – Information about the database at time of execution.
o StatName – Name of the Statistic being updated.
o ActionTaken – The command being executed to update the Statistic.
o Parent_UPS_ID – Stores the UPS_ID as a way to determine all of the Statistics updated for a specific
database on a specific run.
Additional Info:
28
Hydra
Hydra Admin Database Views
VW_OBJECT_LIST


Description: Provides a unified view of object version information.
Definition:
o Columns:
 Type – The object type.
 Name – The name of the object.
 Version – The version number of the object.
 DateCreated – The date the object was created.
 Description – A description of the object.
o Tables:
 OBJ_VER
 OBJ_TYPE
Hydra Admin Functions
GetDatabase



Description: Designed to collect a list of databases.
Parameters:
o DatabaseList – Accepts a string.
 NOTE: The values should be database names separated by a comma.
 i.e. ‘master,msdb’
 NOTE: There are certain key values that automatically assign database names. The values and
functions are as follows.
 SYSTEM_DATABASES – Applies only system database names to the list.
 USER_DATABASES – Applies only user created database names to the list.
 ALL_DATABASES – Applies ALL database names to the list.
Returns:
o A list of database to be used by other procedures.
Hydra Admin Stored Procedures
Hydra_AlertLog


Description: Processes the alerts generated by instance to determine whether notification should be sent.
Parameters:
o DBName – Name of the database submitted by the SQL Agent Token.
o SrvName – Name of the server submitted by the SQL Agent Token.
o Date – Date of the occurrence as submitted by the SQL Agent Token.
 NOTE: This is an integer data type.
29
Hydra
o


Time – Time of the occurrence as submitted by the SQL Agent Token.
 NOTE: this is an Integer data type.
o Severity – Severity level of the alert triggered as submitted by the SQL Agent Token.
o Error – Error number as submitted by the SQL Agent Token.
o Message – The Message generated by the alert as submitted by the SQL Agent Token.
Sample Syntax:
o EXEC [Hydra_Admin].[dbo].[Hydra_Alertlog] '$(ESCAPE_SQUOTE(A-DBN))', '$(ESCAPE_SQUOTE(A-SVR))',
'$(ESCAPE_SQUOTE(STRTDT))', '$(ESCAPE_SQUOTE(STRTTM))', '$(ESCAPE_SQUOTE(A-SEV))',
'$(ESCAPE_SQUOTE(A-ERR))', '$(ESCAPE_SQUOTE(A-MSG))'
Features:
o Procedure uses the MailProfile parameter with a scope of ALL stored in the PRM_LIST table as a way to
designate which configured Mail Profile should be used on the instance.
o Procedure users the DBA Alerts parameter with a scope of ALL stored in the PRM_LIST table as a way to
designate which configured Email Addresses should be sent an email notification.
o Procedure users the DBA Text Alerts parameter with a scope of ALL stored in the PRM_LIST table as a way
to designate which configured Email Addresses should be sent a text notification.
Hydra_BackupPathSetup




Description: This stored procedure will create the folder structure for FULL, DIFF and LOGS locations at the
designate folder location.
Parameters:
o BackupPath – Path of the backup location to create folder structure.
Sample Syntax:
o EXEC [Hydra_Admin].[dbo].[Hydra_BackupPathSetup] ‘C:\SQLBackups’
Features:
o The following folders are created:
 FULL\
 FULL\msdb\
 DIFF\
 DIFF\msdb\
 LOGS\
 LOGS\msdb\
o NOTE: Run the statement once for the Primary Backup Location and once for the Alternate Backup
Location.
Hydra_BlockingNotification



Description: This stored procedure will perform a check on the system to see if there are any SPIDs that are being
blocked. An email alert will be triggered if there are any.
Parameters:
o NONE
Sample Syntax:
30
Hydra

o EXEC [Hydra_Admin].[dbo].[Hydra_BlockingNotification]
Features:
o Flag to determine whether email notifications should be sent.
Hydra_CalcAvgRuntime




Description: This stored procedure will gather all of the individual execution times for all SQL Agent jobs,
determine the average runtime, and calculate this average by a factor as a way to derive a value determined to
be excessive for each individual SQL Agent job on the instance.
Parameters:
o NONE
Sample Syntax:
o EXEC [Hydra_Admin].[dbo].[Hydra_CalcAvgRuntime]
Features:
o Configurable notification levels for each distinct SQL Agent Job.
 1 – High Priority – Email and Text message.
 2 – Medium Priority – Email alert.
 3 – Low Priority – Logged, but not alerted.
o Automatically detects newly added SQL Agent Jobs and notifies Admin of the need to set the severity for
the new job.
Hydra_CheckForLRJ




Description: This stored procedure will to see if any currently executing SQL Agent jobs have exceeded their
expected Run Time Threshold. If so, depending on the Severity Level set, an alert may be sent.
Parameters:
o NONE
Sample Syntax:
o EXEC [Hydra_Admin].[dbo].[Hydra_CheckForLRJ]
Features:
o Send a notification based on severity level.
o Logs all infractions to an LRJ_Log table.
Hydra_CleanUpLogs


Description: This stored procedure will delete records from the various log tables within Hydra_Admin.
Parameters:
o NumberOfMonths – Accepts an integer to represent the number of months to go back in time.
o LogTableAffected – Accepts an integer between the numbers of 1 through 7.
 1 = Backup Log (BKU_Log)
 2 = Blocking Log (BLK_Log)
 3 = Deadlock Log (DLK_Log)
31
Hydra


 4 = Index Maintenance Log (IDX_Log)
 5 = Statistics Update Log (UPS_Log)
 6 = Integrity Check Log (ICE_Log)
 7 = Long Running Job Log (LRJ_Log)
Sample Syntax:
o EXEC [Hydra_Admin].[dbo].[Hydra_CleanUpLogs] 1, 1
Features:
o Allows for custom configuration of deletion patterns for each specific log type.
Hydra_CommandExecute




Description: This stored procedure will log the execution of dynamic commands.
Parameters:
o Command – Accepts any length string containing the command being executed.
o Comment – Accepts any length string containing the comment related to the command.
o Mode – Accepts an integer to determine whether to actually execute the command or just run in debug
mode.
 1 = Debug
 2 = Actual Execution with Try/Catch logging events.
o Execute – Flag to indicate actual execution
 ‘Y’ – Execute (Default)
 ‘N’ – No Execute
Sample Syntax:
o EXEC [Hydra_Admin].[dbo].[Hydra_CommandExecute] ‘Select Top 1 * from sys.databases’, ‘Get top 1
database from master database’, 2 , ‘Y’
Features:
o Allows for troubleshooting of execution events without actually having to run command.
Hydra_DatabaseBackups


Description: Execute the backup processes for the environment.
Parameters:
o BackupType – Accepts a specific set of strings to determine the backup type to be executed.
 FULL = Full Backups
 LOGS = Transaction Log Backups
 DIFF = Differential Backups
o BackupPath – Accepts a string value no larger than 512 characters to determine the Primary Backup
path.
 Sample Value 1: ‘C:\SQLBackups’
 Sample Value 2: ‘\\MachineName\ShareName\SQLBackups’
 NOTE: The value can have an ending backslash “\” and it also accepted.
o AlternateBackupPath – Accepts a string value no larger than 512 characters to determine the Alternate
Backup path.
32
Hydra


 Sample Value 1: ‘C:\SQLBackups’
 Sample Value 2: ‘\\MachineName\ShareName\SQLBackups’
 NOTE: Accepts a NULL value
 NOTE: The value can have an ending backslash “\” and it also accepted.
o RetryCount – Accepts an integer of any value to determine the number of times the Backup Attempt will
be retried before moving to the next logic step.
 Recommended value is 2.
o Compression – Accepts an integer of either a 0 or 1 to determine whether the backups should be
compressed.
 0 = No Compression Enabled (if applicable)
 1 = Compression Enabled (if applicable)
 NOTE: When compression is enabled, if the SQL Version or Edition does not support native
database backup compression, the compression syntax will NOT be applied.
o ConserveSpace – Accepts an integer within a specific range to determine whether the Trace Flag is enabled
or not.
 0 = Do not enable Conserve Space
 1 = Enable Conserve Space
o DBList - Accepts any string value representing a list of databases to either include or exclude from this
execution.
 Sample Value 1: ‘master,msdb,Hydra_Admin’
 Sample Value 2: ‘ALL DATABASES’
 NOTE: Must have commas in between each value, if multiple values are desired.
o Exclude – Accepts a Boolean value to determine whether to perform an exclusion or inclusion of the
database list in the DBList parameter.
 0 – False (Include)
 1 – True (Exclude)
Sample Syntax:
o EXEC [Hydra_Admin].[dbo].[Hydra_DatabaseBackups] ‘DIFF’, ‘C:\SQLBackups’, ‘Q:\SQLBackups’, 2, 1, 0,
‘ALL DATABASES’, 0
Features:
o Retry – The RetryCount parameter will dictate how many times the process will try to execute the backup
command. Upon reaching limit, a failure is logged in the BKU_Log table.
o Alternate Path – The AlternatePath parameter will identify an alternate location to attempt to perform a
backup if the BackupPath parameter location exceeds the RetryCount parameter with failures. The
AlternatePath has the same number of retries as the BackupPath.
o Backup File Size Tracking – The process will log the size of the backup file created during its execution for
all three backup types. The size logged is either a compressed or non-compressed size depending on what
values are stored within MSDB.
o Backup Duration Tracking – The process will log the duration in minutes the backup execution took to
complete.
o Multiple Backup Types – The same stored procedure can be configured to execute Full Backup (FULL),
Differential Backup (DIFF) or a Transaction Log Backup (LOGS) using the same retry and logging
mechanisms.
33
Hydra
o
o
o
o
o
Backup Failure/Retry Notification – The process will send an email indicating a database backup process
failed or completed with a retry event.
Conserve Space is a specific trace flag whereby the current backup will not create a “hollow” file the same
size as the max size of the database, prior to starting the backup. This can be helpful in space constraint
environments. As a byproduct if having to enlarge the file dynamically during the backup process, the
actual backup process may run a longer by as much as 5% - 10% longer in duration.
Can be configured to backup specific databases by now allowing for an inclusion or exclusion list of
databases for a specific execution of this process.
In the event of a missing Full Backup when performing either a Differential or Transaction Log backup, a
Full backup is performed in place of the scheduled backup to ensure next execution of either one is
successful.
AlwaysOn Availability Groups supported.
 Full Backups will be performed with the Copy-Only option enabled.
 If replica is not a preferred backup, then a log entry explaining why the database backup
was not performed.
 Differential backups will create a log entry explaining why the database backup was not
performed.
 Transaction Log will be performed with no special logic.
Hydra_DiskFreeSpaceAlert




Description: This stored procedure is used to check the amount of free space on the disk presented to the SQL
Instance.
Parameters:
o Scope – Accepts any string value to help determine what set of parameters in the PRM_List table should
be used with a given execution.
 Default value is ‘Hydra_DiskFreeSpaceAlert’
Sample Syntax:
o EXEC [Hydra_Admin].[dbo].[Hydra_DiskFreeSpaceAlert] ‘Hydra_DiskFreeSpaceAlert’
Features:
o Automatically add records into the PRM_List table for each Drive Letter found with a default value of
‘5120’.
o Can be utilize the Scope parameter to allow for multiple renditions of this procedure’s executions to allow
for additional granularities.
o Can configure each drive letter parameter within the PRM_List/Scope combination to custom values.
Hydra_HistoryClean




Description: This stored procedure is designed to clean up old history backup entries for databases that no longer
exist on the instance and entries that are more than 60 days old for all databases.
Parameters:
o NONE
Sample Syntax:
o EXEC [Hydra_Admin].[dbo].[Hydra_HistoryClean]
Features:
34
Hydra
o
o
Executes sp_delete_database_backuphistory with each database found to not exist on the instance.
Executes sp_delete_backuphistory with a value of 60 days prior from day of execution.
Hydra_IndexOptimize


Description: This stored procedure is designed to perform index maintenance utilizing a variety of parameters.
Parameters:
o DBs – Accepts only string values outlined below to determine what databases to be affected by the
execution.
 There are certain phrases which will gather certain databases.
 ALL_DATABASES – Gathers all databases.
 SYSTEM_DATABASES – Gathers all System databases (excluding TempDB)
 USER_DATABASES – Gathers all non-system databases.
 <DBName1>,<DBName2>
 NOTE: Replace the <DBName#> with a name of a database. Separate the names by a comma.
o FragHighLOB – Accepts only the following values to determine what type of action will be executed when
the FragLvl2 threshold is breached.
 INDEX_REBUILD_OFFLINE (Default)
 INDEX_REORGANIZE
 STATISTICS_UPDATE
 INDEX_REORGANIZE_STATISTICS_UPDATE
 NOTHING
o FragHighNoLOB – Accepts only the following values to determine what type of action will be executed
when the FragLvl2 threshold is breached.
 INDEX_REBUILD_ONLINE
 INDEX_REBUILD_OFFLINE (Default)
 NOTHING
o FragMidLOB – Accepts only the following values to determine what type of action will be executed when
the FragLvl1 threshold is breached and FragLvl2 threshold is NOT breached.
 INDEX_REBUILD_OFFLINE
 INDEX_REORGANIZE (Default)
 NOTHING
o FragMidNoLOB – Accepts only the following values to determine what type of action will be executed
when the FragLvl1 threshold is breached and FragLvl2 threshold is NOT breached.
 INDEX_REORGANIZE (Default)
35
Hydra
o
o
o
o
o
o
o
o
o
o
o
o
 NOTHING
FragLowLOB – Accepts only the following values to determine what type of action will be executed when
the FragLvl1 threshold is NOT breached.
 NOTHING (Default)
FragLowNoLOB – Accepts only the following values to determine what type of action will be executed
when the FragLvl1 threshold is NOT breached.
 NOTHING (Default)
FragLvl1 – Accepts an integer from 1 – 100
 Default value is 5
FragLvl2 – Accepts an integer from 1 – 100
PgCntLvl – Accepts an integer that is not a negative number.
SortInTempDB – Accepts a single character string of either ‘Y’ or ‘N’ to determine whether the process
will enable the option of sorting in TempDB.
 Default value is ‘N’
MaxDOP – Accepts an integer between 1 and total number of Logical Processors on the machine made
available to SQL Server.
 Default value is NULL (No limit)
FillFactor – Accepts an integer between 1 and 100 to set the Fill Factor of the indexes being maintained.
 Default value is NULL (100)
LOBCompaction – Accepts a single character string of either ‘Y’ or ‘N’ to determine whether LOB columns
will be compacted.
 Default value is ‘Y’
StatSample – Accepts an integer between 1 and 100 representing the percentage of records to use for
statistics sampling.
 Default value is NULL
PartLevel – Accepts a single character string of either ‘Y’ or ‘N’ to determine whether the process will
perform maintenance at a partition level or not.
 Default value is ‘N’
TimeLimit – Accepts an integer representing the number of seconds the process can run before it stops
executing index maintenance commands.
36
Hydra
o


Execute – Accepts a single character string of either ‘Y’ or ‘N’ to determine whether to actually execute
the statement being generated by the process or just log what would have been executed. (Debug
feature).
Sample Syntax:
o EXEC [Hydra_Admin].[dbo].[Hydra_IndexOptimize] @DBs = 'USER_DATABASES', @FragHighLOB =
'INDEX_REBUILD_OFFLINE', @FragHighNoLOB = 'INDEX_REBUILD_OFFLINE', @FragMidLOB =
'INDEX_REORGANIZE_STATISTICS_UPDATE', @FragMidNoLOB =
'INDEX_REORGANIZE_STATISTICS_UPDATE', @FragLowLOB = 'NOTHING', @FragLowNoLOB = 'NOTHING',
@FragLvl1 = 5, @FragLvl2 = 30, @PgCntLvl = 1000, @FillFactor = 90, @StatSample = 100, @TimeLimit =
3600, @Execute = 'Y'
Features:
o Allows for three different actions against a two-tier threshold structure. This allows each individual
execution of this process to have distinct actions as to how the indexes are maintained.
o Allows for the selection of specific databases.
o Allows for the configuration of the different thresholds.
o Logs all actions to the IDX_Log table.
o Can change the configuration of Resource Usage during execution.
o Can control of window of time the index maintenance is to be performed.
o Can control the fill factor of the specific execution.
Hydra_IntegrityCheck


Description: This stored procedure is designed to perform integrity checks of databases.
Parameters:
o RunType – Accepts one of two integer values, 1 or 2
 1 – All Databases every day
 2 – Split Databases between two days using Odd/Even database ID
o SizePivot – Accepts an integer value representing MBs to help determine the threshold of whether a Full
Integrity Check is performed or just a Physical Only execution.
o IgnorePivotEven – Accepts an integer value between 0 and 7 whereby the number represents the day of
the week allows for the ignoring of the pivot to ensure all databases regardless of size will get a full
integrity check executed. This is used by both the RunType of 1 and 2.
 Default value is 0 (do not ignore pivot)
 1 – Sunday
 2 – Monday
 3 – Tuesday
 4 – Wednesday
 5 – Thursday
 6 – Friday
 7 – Saturday
37
Hydra
o
o
o
IgnorePivotOdd – Accepts an integer value between 0 and 7 whereby the number represents the day of
the week allows for the ignoring of the pivot to ensure all databases regardless of size will get a full
integrity check executed. This is used only by the RunType of 2.
 Default value is 0 (do not ignore pivot)
 1 – Sunday
 2 – Monday
 3 – Tuesday
 4 – Wednesday
 5 – Thursday
 6 – Friday
 7 – Saturday
Sample Syntax:
 EXEC [Hydra_Admin].[dbo].[Hydra_IntegrityCheck] 2, 7, 1
Features:
 Allows for All databases to be checked in one pass.
 Can take database size into account as to whether a full integrity check is performed or one with
Physical_Only enabled.
 Allows for alternating Even/Odd integrity check execution.
 Allows for choosing a day of the week of which the pivot is ignored for both Full Database List and
Odd/Even executions.
 Logs ALL error messages returned during the execution to the ICE_Log table.
 Email notification will result when errors in executing the command or error returned from the
actual check results.
Hydra_RestartNotification




Description: This stored procedure performs a check to see if the TempDB has been created recently, thus
indicating the restarting of the SQL Instance.
Parameters:
o None
Sample Syntax:
o EXEC [Hydra_Admin].[dbo].[Hydra_RestartNotification]
Features:
o Can send email and text messages.
o It is trigger by the restarting of SQL Agent.
Hydra_UpdateStats


Description: This stored procedure performs Statistics Updates based on the parameter values provided.
Parameters:
o Databases – Accepts only string values outlined below to determine what databases to be affected by the
execution.
 There are certain phrases which will gather certain databases.
 ALL_DATABASES – Gathers all databases.
 SYSTEM_DATABASES – Gathers all System databases (excluding TempDB)
38
Hydra


 USER_DATABASES – Gathers all non-system databases.
 <DBName1>,<DBName2>
 NOTE: Replace the <DBName#> with a name of a database. Separate the names by a comma.
o UpdateOlderThanDays – Accepts an integer providing a threshold to determine whether the statistics
object needs to be updated.
o SampleType – Accepts only string values outlined below to determine the unit of measure to use for the
sample size.
 ‘Rows’
 ‘Percent’ (Default)
o SampleSize – Accepts an integer and depending on the SampleType will determine what an acceptable
value is.
 If Percent, then the value must be between 1 and 100
 If Rows, then the value must be greater than 0
o TimeLimit – Accepts an integer representing the number of seconds this process is allowed to execute.
o Execute – Accepts a single character string of either ‘Y’ or ‘N’ to determine whether to actually execute
the statement being generated by the process or just log what would have been executed. (Debug
feature).
Sample Syntax:
o EXEC [Hydra_Admin].[dbo].[Hydra_UpdateStats] @Databases = 'USER_DATABASES',
@UpdateOlderThanDays = 7, @SampleSize = 100, @TimeLimit = 3600, @Execute = 'y'
Features:
o Allows for the selection of specific databases.
o Logs all actions to the UPS_Log table.
o Can control of window of time the Statistics maintenance is to be performed.
o Can set the threshold in days to determine whether the Statistic object should be updated.
o Can control the Sample Type and the Sample value to use.
39

help file and technical documentation

Transcription

Similar documents

Industial ink jet printer - harsh environments

Hydra Set Brochure

Hydra Line Products Brochure - Trailer Store and Truck Accessories

Changing Ringtones and Alert Tones

Changing Ringtones and Alert Tones

How To Use Rsync Backup Module

2013 UF Alert Summary

Jacksonville Jaguars Select Cloud-Based Data Protection

XRS 747

Superstudio — polis — Claire Fontaine — Hydra — Juan A. Gaitán

Basics Of Online Banking - Langley Federal Credit Union

User`s Guide