Exploring HADR, Logs, and Configuration

This section covers the following key areas:

• Using the HADR Dashboard
  
  • Monitoring the Log Shipping
  • Monitoring Cluster Services
  • Tracking the Status of the Mirroring Operation
  • Monitoring AlwaysOn Availability Groups
• Using the Logs Dashboard
  • Monitoring the SQL Server Error Logs
  • Monitoring the SQL Agent Error Logs
• Monitoring Configuration Settings
  • Monitoring SQL Server Configuration
• Viewing the SQL Server Configuration Options

Using the HADR Dashboard

The HADR dashboard provides monitoring information regarding the disaster recovering solutions provided by SQL Server: Log Shipping, Cluster, Mirroring, and AlwaysOn. While the data in the Log Shipping dashboard is available for all versions of SQL Server:

• The Cluster dashboard data is only available for instances running on a cluster server that is installed on Windows platform.
• The Mirroring dashboard data is only available for instances that are running on Windows platform and have databases configured for database mirroring.
• The AlwaysOn dashboard requires a SQL Server version equipped with the AlwaysOn capability (SQL Server 2012 and higher).

Monitoring the Log Shipping

Log shipping is used for setting up backup databases to take the place of a current “live” database if that database goes down. To that end, database logs that are dumped on the live database are copied to the backup server and restored on the backup database. Monitoring log shipping requires connecting to a monitor server (which may be the live server, one of its backups, or an outside monitor that does not take place in the log shipping process). The monitoring server is used for analyzing log shipping performance.

Foglight for SQL Server monitors log shipping for the following types of errors:

• Backup threshold exceeded — the failure to back up a database log within a set period of time.
• Out of Sync threshold exceeded — the failure to restore a database log to a backup server within a set period of time after the log has been backed up.

The Log Shipping dashboard allows investigating the cause for a log shipping alarm by carrying out the tasks detailed in the following topics:

• Tracking the Performance of Servers used in Log Shipping
• Viewing the Log Shipping Details

Tracking the Performance of Servers used in Log Shipping

The Log Shipping table contains performance details for the primary and backup servers used in Log Shipping, as presented in the table below. To create a custom filter for this table, use the options accessible by clicking Advanced.

The Log Shipping table contains performance details.

Column	Description
Server	The server name (Primary server for the parent instance, and Secondary server for all subsequent child instances).
DBName	Depending on the instance role: - For the primary instance, the backup database on the source server - For the secondary instance, the destination database on the secondary server.
Last Activity	Depending on the instance role: - For the primary instance, the last time the database was backed up - For the secondary instance, the last time a file was copied or restored
Activity Type	What activity was performed at the Last Activity time (Backup or Copy).
Threshold	The maximum allowed time (in minutes) before a Log Shipping alert occurs. The amount of time depends on the instance role: - For the primary instance, this is the maximum allowed time since the last transaction log backup was made on the source server. - For the secondary instance — the maximum allowed time between the last backup on the source server and the last restore on the secondary server.
Outage	During an outage, no alerts occur when thresholds are exceeded (for both the parent and child instances). If this field is blank, no outage takes place.
Threshold Alert	The Error Log dashboard displays this alert if the threshold is exceeded.
Alert Enabled	If this option is selected, only enabled alerts are displayed.

Viewing the Log Shipping Details

The Log Shipping Details section displays the following indicators about the currently selected activity:

Column	Description
Last Backup File	The name of the most recent backup file.
Last File Copied	The name of the most recent backup file that was copied to the secondary server.
Last File Restored	The name of the backup file that was most recently restored to the secondary server.
Backup Time	The time when the most recent backup was carried out.
Copy Time	The date the backup file was most recently copied from the primary to the secondary server.
Restore Time	The date the backup file was most recently restored to the secondary server.
Under the Current Time section:
Source Server	The current timestamp at the primary server.
Target Server	The current timestamp at the secondary server.
Monitor Server	The current timestamp at the monitor server.

Monitoring Cluster Services

The Cluster Services dashboard displays information about the state of the current Microsoft Cluster Server.

This dashboard is used for investigating the causes for the Cluster Server Down alarm, which is raised when Foglight for SQL Server detects that at least one cluster node (server) is not currently running as part of the cluster. The Cluster Services dashboard provides only tabular information, using the Cluster Services table.

Monitoring the State of the Current Microsoft Cluster Server

The Cluster Services table displays information about the state of the currently monitored Microsoft Cluster Server. This table allows viewing the status of each cluster resource and group, as well as the status of any cluster resources owned by each server (node) in the cluster. Foglight for SQL Server highlights any unusual conditions such as resources offline, or cluster nodes down. To create a custom filter for this table, use the options accessible by clicking Advanced.

The Cluster Services table displays indicators of the Cluster Server performance:

Column	Description
Name	The hierarchical tree of cluster resources, the root of which is the name of the cluster.nLower levels in the tree represent cluster groups, resource groups and servers, and resource details.
Status	The status of the current resource (where applicable).
Server	The individual server in the cluster where the specified resource is located.
Comment	A brief description of the specified cluster resource (if available).

Tracking the Status of the Mirroring Operation

If one or more databases within the monitored instance take part in a mirroring operation, either as a principal database whose exact copy is mirrored on a different instance, or as a mirror database, the Mirroring dashboard allows viewing the status of the mirroring operation.

If no database within the monitored instance takes part in a mirroring operation, the Mirroring dashboard is left blank and displays the note This instance has no database configured for database mirroring.

If the monitored instance supports the AlwaysOn feature (supported only for SQL Server version 2012 Enterprise edition), AlwaysOn cannot function at the same time with Mirroring operation: enabling Mirroring requires disabling AlwaysOn and conversely. Therefore, if the monitored instance contains databases that have AlwaysOn enabled, the Mirroring dashboard displays the note: This instance has no database configured for database mirroring.

The Mirroring dashboard includes the following sections:

• Mirroring table
• Role and data flow of the selected database

In addition, this dashboard allows further investigation of the selected database, by drilling down to other locations.

• Investigating using the Databases drilldown — carried out by clicking the instance name under the Database column.
• Viewing the database’s mirroring performance history — carried out by clicking the instance’s mirroring role (MIRROR or PRINCIPAL) under the Mirroring Role column.
• Investigating using the partner’s mirroring page — carried out by clicking the link at the upper right side of the screen or the Mirror database icon under the section Role and Data Flow of the Selected Database.

Mirroring Table

The Mirroring table displays the columns listed below. The table below provides data about the columns that appear by default in the table.

Mirroring table, default columns:

Column	Description
DBID	A number (ID) uniquely identifying a database within a SQL Server.
Database	The database name. Note: The database name appears as a link which, when clicked, displays the Databases dashboard in Overview mode, with the selected database highlighted in the Databases table and its details displayed in the panes below.
Mirroring Role	The role the database takes in the mirroring process; either principal or mirror. Note: The mirroring role is displayed as a link which, when clicked, displays the mirroring performance history of the selected database.
Principal	The name of the instance whose role in the process is principal.
Mirror	The name of the instance whose role in the mirroring process is mirror
Mirroring Status	Indicates the severity determined based on the database state: Normal, Warning, or Critical. Each of these severity level values can correspond to several mirroring states. Normal — can correspond to one of the following mirroring states: - SYNCHRONIZED (with a Witness) - SYNCHRONIZED (without a Witness) Note: To view whether the mirroring operation is configured to use a Witness, click the Customizer button at the end of the table and turn on the display of the Witness Name and Witness State columns. - SYNCHRONIZING Warning — can correspond to one of the following mirroring states: - DISCONNECTED - PENDING_FAILOVER Critical — can correspond to one of the following mirroring states: - SUSPENDED - UNSYNCHRONIZED
Mirroring State	A state indicating the mirroring session condition. This field can have one of the following values: - DISCONNECTED - SYNCHRONIZED (with a Witness configured) - SYNCHRONIZING - PENDING_FAILOVER - SUSPENDED - UNSYNCHRONIZED - SYNCHRONIZED (without a Witness configured)
Safety Level	The safety level at which the mirroring session is configured to work. This column indicates the level of synchronization between the two servers that take part in the mirroring process. This field can have one of the following values: - UNKNOWN — unknown state - OFF — high availability (asynchronous). When an instance is configured with this safety level, the main consideration is that it remains available, regardless of the availability of its mirroring partner. - FULL — high safety (synchronous). The instance is configured to fail over when its mirroring partner becomes unavailable. Failover can be carried out automatically (if a Witness is configured) or manually
Redo Queue	The redo queue size. This size can be either left Unlimited or defined in megabytes (MB).
Alarms	The number of warning, critical, and fatal alarms for the SQL Server database instance. When holding the cursor over one of the alarm counts, the dwell displays the most recent alarms raised against this database, sorted by severity. Clicking this field displays the Alarms list, which is listed by severity order.

Additional metrics in the Mirroring table

The metrics listed below, which are also part of the Database Mirroring collection, do not appear by default in the Mirroring table. To display the metrics listed below:

1. Click the Customizer button at the end of the table.
2. Select the check box near the requested metric.

Additional metrics list

• Failover LSN
• End Log LSN
• Replication LSN
• Witness State
• Connection Timeout
• Partner Name
• Witness Name
• Role Sequence
• Log Scanned For Undo
• Log Remaining For Undo
• Mirroring Roundtrip - Latency
• Commit Acknowledgement Delay
• Write Commit
• Log Sent
• Log Send Flow Buffer Wait
• Log Sent From Cache
• Send Queue
• Roll Forward Queue
• Log Received
• Log Rolled Forward
• Log Cache Redone
• Log Harden Wait Time

Viewing the Role and Data Flow of the Selected Database

The Role and Data Flow of Database section displays the mirroring operation of the database selected in the Mirroring table and its mirroring partner. The monitored instance is always displayed on the left, and the data is shown as flowing in this instance’s direction, that is: Log Received if the database is Mirror, and Log Sent if the database is Principal.

To investigate the data flow by displaying the selected database’s mirroring partner, use one of the following methods:

• Click the cylinder icon that represents the mirroring partner
• Click the link Investigate using the Partner’s Mirroring Page on the upper right side of the dashboard, above the table.

If the partner is currently monitored, its mirroring page will now be displayed. Otherwise, an error message is displayed, notifying that the partner server is currently not monitored.

Viewing the Selected Database’s Mirroring Performance History

Clicking the Mirroring Role column of the Mirroring table displays the database’s Mirroring Performance History page, which allows carrying out the tasks described in the following sections:

• Tracking the mirroring role over time
• Tracking data transfer between the principal and the mirror databases
• Tracking the mirroring roundtrip during the selected time range

Tracking the mirroring role over time

The Mirroring Role pane displays the role the database played in the mirroring operation during the selected time range: Principal, Mirror, or Not Mirroring. The mirroring role is displayed as a gauge, with each of the mirroring roles indicated by another color. Positioning the cursor over the gauge displays the percentage, within the specified time range, the database spent in each role.

Tracking data transfer between the principal and the mirror databases

The middle section of the Mirroring Performance History page includes the following panes:

• Principal Counters — this pane displays a chart of the following values, which can be selected from the list on the upper left:
  • Commit Acknowledgement Delay — indicates a delay in waiting for acknowledgement of unterminated transaction commit. This metric is specific to the principal database, and holds values only when a Full safety level is configured.
  • Write Commit — the number of transactions in the principal database that had to wait for a write commit in the mirror database’s transaction log. Low values of this metric indicate a bottleneck.
  • Log Sent — indicates the rate, in megabytes, of log sent from the principal to the mirror database.
  • Log Send Flow Buffer Wait — the amount of time the mirroring session had to wait to use the mirroring flow control buffer. This value is specific to the principal database.
  • Log Sent from Cache — indicates the aggregated size, in megabytes, of the log records sent from the principal database cache rather than straight from the transaction log.
  • Send Queue — total size, in megabytes, of data waiting to be sent to the mirroring database.
• Mirror Counters — this pane displays a chart of the following values, which can be selected from the list on the upper left:
  • Roll Forward Queue — total size, in megabytes, that remains to roll forward to the mirroring database.
  • Log Received — indicates the aggregated size, in megabytes, of log records received from the principal database.
  • Log Rolled Forward — the aggregated size, in megabytes, of log records that were rolled forward on the mirror database.
  • Log Cache Redone — the aggregated size, in megabytes, of log records that are being read from redo cache rather than from the transaction log. Constantly low values of this metric indicate that the transaction logs are arriving faster than they can be read by the redo task. This metric is specific to the mirror database.
  • Log Harden Wait Time — the amount of time spent waiting for the log to be written to the mirroring database. High values of this metric can indicate that the disk of the mirroring database is loaded.

Tracking the mirroring roundtrip during the selected time range The Mirroring Roundtrip section displays a chart that indicates the latency of the mirroring session during the selected time range.

Viewing the Partner’s Mirroring Page

When viewing the mirroring performance of a database that takes part in the mirroring operation, either as a principal or as a mirror database, it is possible to investigate the selected database’s mirroring partner, using one of the following methods:

• Clicking the cylinder icon that represents the mirroring partner
• Clicking the link Investigate using the Partner’s Mirroring Page on the upper right side of the table.

In so doing, the mirroring operation can be investigated from the point of view of the other database, thereby determining the source of the performance issue.

Monitoring AlwaysOn Availability Groups

The AlwaysOn dashboard requires a SQL Server version that includes the AlwaysOn Availability Group capability (SQL Server 2012 and higher).

The AlwaysOn dashboard includes the following sections:

• OS Cluster information
• High Availability groups table — displays all High Availability groups that are configured on the instance.
• Availability group map tab — displays the dependency (primary/secondary relations) between the databases in the groups selected in the High Availability groups table, or between all groups in the table.
• Group Info tab tab- displays details related to primary replica, primary recovery health, and synchronization health.
• Availability Replica tab- all replicas associated with the group.
• Databases tab- displays all databases associated with the group

OS Cluster Information

The OS cluster information section displays the following details:

• OS Cluster Name — the name of the OS cluster hosting the SQL Server instances that are enabled for AlwaysOn Availability Groups.
• Quorum Type — the type of quorum used by the selected OS cluster; can have one of the following values:
  • 0 — Node Majority.
    The cluster is defined as healthy only if indicated so by more than 50% of the voting nodes in the cluster. For example, on a nine node cluster this quorum configuration can sustain up to four node failures.
  • 1 — Node and Disk Majority.
    This mode is similar to Node Majority quorum mode, with the addition of a shared disk cluster resource as a voting witness. More than 50% of the cluster’s possible votes must be affirmative in order to determine the cluster’s state as healthy, and connectivity from any node to that shared disk is also counted as an affirmative vote.
  • 2 — Node and File Share Majority.
    This mode is similar to Node Majority quorum mode, with the addition of a remote file share configured as a voting witness. More than 50% of the cluster’s possible votes must be affirmative in order to determine the cluster’s state as healthy, and connectivity from any node to that remote file share is also counted as an affirmative vote.
  • 3 — No Majority: Disk Only.
    A shared disk cluster resource is designated as a witness, and connectivity by any node to that shared disk is counted as an affirmative vote.
• Quorum State — the state of the quorum used by the selected OS cluster; can have one of the following values:
  • 0 — Unknown quorum state
  • 1 — Normal quorum
  • 2 — Forced quorum

High Availability groups table

The High Availability group table displays information about the availability and health of all availability groups configured in the instance and the databases they serve.

The High Availability group table includes the following columns:

• HA Group Status — displays an icon that indicates the worst severity reported within the group from the group alarms.
• Group Name — displays the High Availability group name.
• Role — the current state of the database that runs on the selected instance and belongs to the selected group; either Secondary or Primary. When there is no value for Secondary/Primary, this column should indicate the status Off line.
• Alarms — displays alarms related to the health of the availability group or its associated databases.
• Max Estimated Recovery Time — displays the maximum value of the estimated recovery time parameter within all databases that belong to the selected group. If all databases are fully synchronized, this column displays a zero value.
• Max Estimated Data Loss — displays the maximum value of the estimated data loss parameter within all databases that belong to the selected group. If all databases are fully synchronized, this column displays a zero value.

Availability group map tab

The AlwaysOn configuration supports one primary replica and up to four secondary replicas for each availability group. The Availability Group Map section allows viewing the dependencies between the various replicas that form the availability group selected in the table. In addition to indicating the name of the OS cluster where the availability replicas reside, the map displays the connections between the primary replica and the secondary replicas, showing on the left the replica that resides on the currently monitored instance.

Clicking the monitored replica displays a pop-up with the following tabs:

• Group Info — identical to the Group Info tab on the pop-up that appears upon clicking the Explore column on the High Availability groups table.
• HA Summary — displays the selected replica’s availability-related alarms, including the severity and the error message.
• Databases Health — a table displaying all alarms sent during the specified time range, including the severity and the error message.
• Listeners — if one or more availability group listeners are configured, displays the listeners' names and their IP status, either Online or Offline.

Clicking any other replica displays a pop-up with the following tabs:

• HA Summary — displays the selected replica’s availability related alarms, including the severity and the error message.
• Databases Health — a table displaying all alarms sent during the specified time range, including the severity and the error message.

To view the dependencies between all replicas in all availability groups, click View map for all availability groups. To return from this map to the AlwaysOn dashboard, click Back.

Group Info Tab

The Group Info tab includes the following fields:

• Primary replica — the primary replica’s name.
• Primary recovery health — indicates the primary replica’s recovery health, with the following possible values: In progress, Online or Null.
• Synchronization health — summarizes the synchronization status of all replicas in the availability group:
  • Healthy — if all replicas are fully synchronized.
  • Partially healthy — if only some of the replicas are fully synchronized.
  • Not healthy — if no replica is fully synchronized.
• Automated backup preference — indicates whether backups should run on the primary replica. The possible values are:
  • 0 - Primary — backups should always be carried out on the primary replica.
  • 1 - Secondary_only — performing backups on a secondary replica is preferable.
  • 2 - Secondary — performing backups on a secondary replica preferable, but performing backups on the primary replica is acceptable if no secondary replica is available for backup operations. This is the default behavior.
  • 3 - None — no preference about whether backups are performed on the primary replica or on a secondary replica.

Availability Replica tab

This tab lists all replicas associated with the group. This tab includes the following fields:

• Server Name — the name of the server.
• Join State — can have the following values:
  • Not joined
  • Joined standalone — joined as a standalone instance
  • Joined Failover — joined as failover cluster instance
• Role — either Primary or Secondary.
• Operational State — indicates whether the replica is online, offline or in a pending stage. The possible values are as follows:
  • Pending failover
  • Pending
  • Online
  • Offline
  • Failed, no quorum
  • Null — replica is not local
• Connected State — indicates whether a secondary replica is currently connected to the primary replica. Possible values are either Connected or Disconnected.
• Recovery Health — indicates whether all databases joined to the availability group on the availability replica, are online, or are being recovered after a failover. Possible values are:
  • Online
  • In progress — recovering from a failover
• Synchronization Health — summarizes the synchronization status of all replicas in the availability group:
  • Healthy — if all replicas are fully synchronized.
  • Partially healthy — if only some of the replicas are fully synchronized.
  • Not healthy — if no replica is fully synchronized.
• Secondary Role Allow Connections — indicates whether an availability replica that is performing the secondary role (that is, a secondary replica) can accept connections from clients:
  • No — no connections are allowed to the databases in the secondary replica, and the databases are not available for read access. This is the default setting.
  • Read only — read-only connections have exclusive access to the databases in the secondary replica. All databases in the replica are available for read access.
  • All — all connections are allowed to the databases in the secondary replica for read-only access.
• Availability Mode — can have either of the following values:
  • Asynchronous commit — the primary replica can commit transactions without waiting for the secondary to write the log to disk.
  • Synchronous commit — the primary replica waits to commit a given transaction until the secondary replica has written the transaction to disk.
• Failover Mode — either Manual or Automatic.

Databases tab

This tab displays all databases associated with the group. This tab includes the following fields:

• Replica Server Name — the name of the server.
• Database Name — the name of the database.
• Database State — indicates whether the database is online, offline or in a pending stage. The possible values are as follows:
  • Online
  • Restoring
  • Recovering
  • Recovery pending
  • Suspect
  • Emergency
  • Offline
• Synchronization State — indicates the data movement state, and can have one of the following values:
  • Not Synchronizing
  • Synchronizing
  • Synchronized
  • Reverting pages from undo log
  • Initializing Undo log
• Synchronization Health — summarizes the synchronization status of all replicas in the availability group:
  • Healthy — if all replicas are fully synchronized.
  • Partially healthy — if only some of the replicas are fully synchronized.
  • Not healthy — if no replica is fully synchronized.
• Estimated Recovery Time (sec) — the estimated time that the secondary replica will require in order to catch up with the primary replica.
• Estimated Data Loss (sec) — the time difference of the last transaction log record between the primary and secondary replicas. Failure of the primary replica will result in the loss of all transaction log records within the time window.
• Is Failover Ready — indicates whether the secondary database is synchronized in the cluster with the corresponding primary database. Possible values are Yes or No.
• Log Send Queue Size (KB) - Amount of log records of the primary database that has not been sent to the secondary database, in kilobytes (KB).
• Redo Queue Size (KB) - Amount of log records in the log files of the secondary replica that has not yet been redone, in kilobytes (KB).
• Log Send Rate (KB/sec) - Rate of primary database log records that has been sent to the secondary database
• Redo Rate (KB/sec) - Rate of log records in the log files of the secondary replica that has been redone
• Hardened Latency - The length of time between the time the last log block was sent and the Hardened Time.
• Commit Latency - The length of time between the time the last log block was sent and the Commit Time.
• Last Sent Time - Time when the last log block was sent.
• Last Received Time - Time when the log block ID in last message received was read on the secondary replica.
• Last Hardened Time - On a secondary database, time of the log-block identifier for the last hardened LSN (last_hardened_lsn). On a primary database, reflects the time corresponding to minimum hardened LSN.
• Last Redone Time - Time when the last log record was redone on the secondary database.
• Last Commit Time - Time corresponding to the last commit record.

Using the Logs Dashboard

The Logs dashboard provides access to SQL Server Error Log and SQL Server Agent Error Log. To configure which error logs generated by the SQL Server database are to be displayed in the Logs dashboard, use the Error Log Scanning view in the Databases Administration dashboard.

Monitoring the SQL Server Error Logs

The SQL Server Error Logs dashboard displays errors that are defined in the match list and can be viewed by a paging resolution of 1 hour. This dashboard contains the following items:

• List of current and archived error logs
  Use this list to choose the error log whose details are to be displayed in the Error Log table below.
• Error Log table — displays the following parameters.

Error log table parameters:

Column	Description
Date/Time	The date and time when the specified error was logged.
Process Info	Information about the process to which the entry in the error log refers.
Message	A brief description of the error.

The SQL Server Error Logs table displays the contents of the error log selected in the list above the table. This table is a snapshot of the selected error log, and is therefore not updated automatically. To define and edit the alert rules for which Foglight for SQL Server scans the SQL Server Error Log, go to the Error Log Scanning view in the Databases Administration dashboard. To access this view, click the In-context actions button at the upper right side of the screen and then select Agent settings.

Monitoring the SQL Agent Error Logs

The SQL Agent Error Logs dashboard displays errors that are defined in the match list and can be viewed by a paging resolution of 1 hour. It contains the following items:

• List of current and archived error logs
  Use this list to choose the error log whose details are to be displayed in the Error Log table below.
• Error Log table — displays the following parameters.

Error log table parameters:

Column	Description
Date/Time	The date and time when the specified error was logged.
Message	A brief description of the error. This description can also provide the reason for the error, thereby helping to resolve the issue; for example, Unable to start mail session (reason: no mail profile defined).

Monitoring Configuration Settings

The Configuration dashboard displays the various SQL Server configuration options.

Monitoring SQL Server Configuration

The SQL Server Configuration dashboard allows carrying out the following tasks:

• Viewing the server property values — using the Server Property Values dashboard.
• Viewing the SQL Server configuration options — using the Configuration table.

Viewing the Server Property Values

The Server Property Values dashboard contains information about the server properties of the monitored SQL Server instance.

The Server Property Values parameters:

Parameter	Description
SQL Server Version	Version number of the currently monitored SQL Server instance.
Windows Version	The full version number of the Windows operating system installed on the computer that runs the SQL Server instance (including build and service pack).
Processor Type	The processor type (usually a vendor code).
Processor Count	The number of processors on the computer on which Windows is installed.
Physical Memory	The amount of actual RAM in the monitored host.
Collation	Default collation for databases on the SQL Server instance. Unless another collation is specified when creating a new database, this collation will apply to all of the instance’s databases.

Viewing the SQL Server Configuration Options

The SQL Server Configuration table displays the configuration parameters for the currently monitored SQL Server, as listed in the table below. These parameters often affect the system’s performance. Therefore, reviewing the values displayed in this table and modifying them, if needed, may successfully resolve performance issues. To create a custom filter for this table, use the options accessible by clicking the button at the table’s upper right side.

The SQL Server Configuration table parameters:

Parameter	Description
Configuration Name	The name of the specified configuration option.
Run Value	The value currently used by the configuration option.
Configuration Value	The value to which the configuration option is set. Depending on the Modifiable setting, changing the Config value can be implemented either immediately or only after restarting SQL Server.
Previous Value	The configuration option’s value before the last change took place.
Last Change Time	The time the most recent change took place.
Min	The minimum permitted value for the configuration option.
Max	The maximum permitted value for the configuration option.
Modifiable	Indicates when changes to the option take effect. The following options are possible: - Immediate: changes to these options take effect immediately. - Restart: changes to these options take effect after SQL Server is stopped and restarted. - Never: these options cannot be modified.
Description	Description of the specified configuration option.