Server Variables

functional

Search status counters and configuration, and change dynamic settings through reviewed SQL.

Right-click a server in the Object Explorer and choose Properties.... Next to the Configuration page, the Status page lists the server's status counters. Both pages have a search box, and on engines that allow it you can change dynamic settings from Configuration. Every change goes through a review step first.

Status counters

The Status page reads the engine's own counter catalog and shows it as a grid of Counter, Value, and Class. It is the full list, not the handful of tiles the Server Dashboard shows. Type in the search box to narrow it by name, value, or class. The count next to the box shows how many rows match out of the total. Refresh re-reads the counters.

Engine	Counters come from
SQL Server	`sys.dm_os_performance_counters`, limited to the main object classes (Buffer Manager, Access Methods, General Statistics, SQL Statistics, Locks, and so on) and to counters that make sense on their own. Ratio counters that need a base counter are left out.
PostgreSQL	Totals across all databases from `pg_stat_database`, plus `pg_stat_bgwriter`.
MySQL	`performance_schema.global_status` (the same data as `SHOW GLOBAL STATUS`).
MariaDB	`information_schema.GLOBAL_STATUS`.
ClickHouse	Gauges from `system.metrics` and running totals from `system.events`.
Oracle	`v$sysstat`, user and cache classes. Needs `SELECT_CATALOG_ROLE`; without it the page shows the server's error.
Redis	`INFO`, with each section as the class.
SQLite, DuckDB, libSQL, CockroachDB	None. The page says why: an in-process file, one request at a time, or cluster metrics that live in `crdb_internal`.

Server Properties, Status page: searchable status counters with the matching-row count.

Changing dynamic settings

On the Configuration page, select a setting. If the engine lets you change it while the server is running, an edit strip appears under the grid with the current value in an input. Type the new value to stage it. Below the strip, a live SQL preview shows the exact statements that will run, and it updates as you type. You can stage several settings before applying. Apply opens the review sheet, and nothing runs until you confirm there. The selection follows the setting you clicked even after you sort or filter the grid.

Engine	What Apply runs	Which settings can change
SQL Server	`EXEC sys.sp_configure N'name', value;` for each setting, then `RECONFIGURE;`. Values are whole numbers, as every `sp_configure` option is. For an advanced option (max server memory, max degree of parallelism, cost threshold for parallelism, ...) while `show advanced options` is off, the script turns it on first and back off at the end, and the review sheet says so. If a statement fails part-way, SQLly switches `show advanced options` back off before reporting the error.	Rows `sys.configurations` marks `is_dynamic`.
PostgreSQL	`ALTER SYSTEM SET "name" = 'value';` for each setting, then `SELECT pg_reload_conf();`. List settings such as `search_path` and `shared_preload_libraries` are written one quoted item at a time. Clearing the value runs `ALTER SYSTEM RESET "name";` instead.	Settings whose context is `user`, `superuser`, `sighup`, or `backend`. Restart-only (`postmaster`) settings stay read-only. Values show in `SHOW` form with their units (`128MB`), which is also what you type.
CockroachDB	`SET CLUSTER SETTING name = 'value';`, or `RESET CLUSTER SETTING name;` when the value is cleared.	The Configuration page lists the cluster settings from `crdb_internal.cluster_settings`, which needs the `VIEWCLUSTERSETTING` privilege (or admin); without it the page shows the server's error.
MySQL	`SET GLOBAL name = value;`. Tick Persist across restart to use `SET PERSIST` instead. Clearing the value sets it to `DEFAULT`.	MySQL's catalogs don't record which variables are read-only, so SQLly marks the documented startup-only ones (such as `datadir`, `port`, and `innodb_buffer_pool_instances`, plus the `have_` and `version` build facts) read-only. The server rejects any other read-only variable when the statement runs, and the error is shown.
MariaDB	`SET GLOBAL name = value;` (MariaDB has no `SET PERSIST`). Clearing the value sets it to `DEFAULT`.	Variables `information_schema.SYSTEM_VARIABLES` marks writable.

Setting changes take effect immediately and can't be rolled back. The review sheet lists each change as Set name to new (was old), and the old value is in a form you can type back in. To undo one, apply it again with the old value. If Apply stops at an error, the statements before it have already taken effect.

The edit strip doesn't offer changes on connections that couldn't apply them, and says why: a SELECT-only connection, a production connection whose writes are locked (unlock from the status bar, then reopen Properties), or a connection set to wrap every batch in a rolled-back transaction. That last one is refused because ALTER SYSTEM, RECONFIGURE, and SET CLUSTER SETTING can't run inside a transaction, and MySQL's SET GLOBAL would take effect despite the rollback.

Values are quoted for each engine: numbers and ON/OFF go in bare where the engine accepts them, and anything else is escaped as a string literal. A setting name that can't be written safely is refused rather than inserted into the SQL. ClickHouse, Oracle, DuckDB, SQLite, libSQL, and Redis stay read-only here, and the strip explains where those settings are changed instead (a session SET, a PRAGMA, CONFIG SET, or a DBA's ALTER SYSTEM).

Configuration page: editing a dynamic setting, with the live SQL preview under the edit strip.

Permissions are the server's. Changing settings needs the server-level right (ALTER SETTINGS, superuser or pg_write_all_settings style grants, SYSTEM_VARIABLES_ADMIN). Without it, Apply shows the server's refusal and the staged changes stay in the review sheet.