SQL Pre-Scanning

SQL Pre-Scanning

< Guide Menu

Assuming your databases have been configured (either statically or through auto discovery), the following workflow will help you get the most out of Quasar’s SQL Scanning capability. These pre-scanning steps are optional, but do have safety and efficiency benefits.

The SQL Scanner can be set to perform a number of distinct Actions. Each action builds upon the last in a sequence, and can be run en masse from the central console by operators, saving time and effort. This page focuses on the pre-scanning. The next page provides guidance for the wide / deep scan process.

SQL Pre-Scan

The actions listed here are equivalent to the deployment-testing actions as listed in Test & Deployment Commands,

Connect Test

Connect test Action

If you are scanning a number of databases in parallel (e.g. via custom AgentGroups), it can be useful to ensure all the databases are connectable before commencing the actual scan. The Connect Test action enables you to do just that.

Each agent tests it’s known databases by connecting to them one after the other. Successful connections are usually effectively instant when the databases are on the same host as the agent (which they are for auto-discovered databases). Unsuccessful connections will usually time out, and time outs are typically in the 30 second to 2 minute range. For this reason it is recommended to pad your job-scheduling window to e.g. 10-20 minutes, even though the majority of the time the job should complete near-instantly.

Connection test results are logged to the Files table, for example:

SQL Connect Test Results

Tables and Columns

The next step is to review tables (and, optionally, columns). Reviewing table names can be useful for a number of reasons:

  • Some databases may have per-table security permissions that are incomplete or misconfigured. Listing the table names can help to ensure that all the expected tables are accounted for before performing a time-consuming scan.
  • It can provide assurance that the scanner isn’t going to query Oracle tables that trigger additional licensing costs. By reviewing the list of tables first, then adding table names to the Oracle table names blacklist, THEN scanning, safety is assured.

Table/Column list results are also logged to the Files table, for example:

SQL Scan List Tables Result

Table and column names are listed, along with whether they will be scanned or not scanned, and if not, why. An example ‘file path’ such as MSSQL:QSVR2008R2-64\SQLEXPRESS:harry/dbo.foo/arr breaks down as:

DB Engine TypeServer-InstanceDatabaseTableColumn
MSSQLQSVR2008R2-64\SQLEXPRESSharrydbo.fooarr
Previous Scanning SQL Databases
Next SQL Scanning – Wide/Deep Process
Table of Contents