LogoLogo
ReleasesHomepageBlogSlack
2.5
2.5
  • Welcome
  • Concept
  • SQLWATCH Database
    • Requirements
      • Permissions
      • Performance Overhead
      • Storage Utilisation
    • Installation
      • Install with dbatools
      • Install with SqlPackage
      • Install with SSMS
      • Deploy from source code
      • Optional Components
      • Upgrade
      • Removal
      • Downgrade
    • Configuration
    • Known Issues
      • Collation conflict
      • Database drift
      • Login failed error when running disk logger
      • Deadlock when creating database
    • Notifications
      • Checks
      • Actions
      • Reports
      • How To
        • Add or modify check
        • Add or modify action
        • Add or modify report
      • Process Flow
    • Large Environments
  • Central Repository
    • Requirements
      • Performance overhead on the remote instance
      • Permissions
    • Installation
      • Removal
      • Upgrade
    • Configuration
    • Known Issues
  • Power BI Dashboard
    • Requirements
      • Permissions
    • Installation
    • Configuration
    • Known Issues
      • Power BI Load Errors
    • Performance
  • Design Decision
    • Relations
    • Trend Tables
    • Data Types
      • Real Type
    • Primary Keys
    • Data Compression
    • Configuration Items
    • Using Apply instead of Join
  • Reference
    • Data-Tier Application Package
  • Integrations
    • Send notifications to Slack and Teams
    • dbachecks
  • FAQ
    • How do I check if SQLWATCH is running OK?
    • I am not seeing any data in Power BI
    • Can I modify default checks?
    • The app_log is growing fast
Powered by GitBook
On this page

Was this helpful?

  1. Design Decision

Configuration Items

SQLWATCH is designed to create minimum performance overhead.

There is a number of configuration items exposed to the end user in the sqlwatch_config* tables. However, for performance reasons, configuration is limited to the required minimum and some variables are either hard coded or assumed.

Image a scenario when everything was configurable, the configuration would have to be stored in a table, and configuration value queried with every execution adding to the workload and, sometimes, making it possible for the query optimiser to pick best execution plan.

An example of such approach is in the action logger, where we do not log actions that have nothing to do. If you want to log all actions, you would need to change the below in usp_sqlwatch_internal_process_actions

--by default, we are NOT logging actions that have no action to do, 
--only those that are triggering a valid action or have error:
if @action_type <> 'NONE' or @action_attributes is not null
	begin
		insert into [dbo].[sqlwatch_logger_check_action] 
			(   [sql_instance], [snapshot_type_id], [check_id]
				, [action_id], [snapshot_time], [action_type], [action_attributes])
		select @@SERVERNAME, 18, @check_id, @action_id, @check_snapshot_time
				  , @action_type, @action_attributes
	end

There could be hundreds of checks and each check could have dozen of different actions and if we were to check a parameter for each execution, we would be potentially running thousands of queries every minute.

PreviousData CompressionNextUsing Apply instead of Join

Last updated 5 years ago

Was this helpful?