When we enable the SQL Auditing we need to be aware of three mainly considerations:
- The connection will be redirected to another endpoint server.
- We have some impact in the connection time and execution time.
- Some data providers don’t have implemented redirection feature.
The connection will be redirected to another proxy server.
- When you enable the SQL Auditing option you need to know that the connection will go instead of through to the endpoint datacenter.control.database.windows.net will go through another endpoint called datasec-xxxxxx.cloudapp.net ( where xxxxxx is special format), see this example, using netsh.
Direct connection to the database.
Connection using the SQL Auditing Endpoint
- If you have defined a restrictive firewall setting, you need to configure from your local applications to be able to connect to these endpoints. You could find out the IPs address and any other information in this URL.
- If you don’t have enabled this firewall rule, you could receive at the connection attempt the following error message trying to connect to your Azure SQL Database: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 0 – Access is denied.)
SQL Auditing Impact in the connection time and execution time.
- Thanks to Provider statistics for SQL Server we have to see the impact in terms of connection and execution command after enabling the SQL Auditing.
- For example, I have created the following table and I added 20000 rows.
CREATETABLE [dbo].[ValoresEjemplo]([ID] [int] IDENTITY(1,1)NOTNULL,[Nombre] [varchar](50)NULL,CONSTRAINT [PK_ValoresEjemplo] PRIMARYKEYCLUSTERED([ID] ASC))
declare @p as int
set @p=0
begin transaction
WHILE @P<20000
begin
set @p=@p+1
insert into [ValoresEjemplo] (nombre) values(‘Ejemplo: ‘ + convert(varchar(20), @p))
end
commit transaction
- Using the following source code I’m going to take the time spent for a TSQL command execution between two databases one with SQL Auditing and another one without it.
using (SqlConnection awConnection = new SqlConnection(connectionString))
{
Stopwatch stopWatch = new Stopwatch();
stopWatch.Start();
awConnection.StatisticsEnabled = true;
string productSQL = “SELECT top ” + nRows.ToString() + “* FROM ValoresEjemplo”;
SqlDataAdapter productAdapter = new SqlDataAdapter(productSQL, awConnection);
DataSet awDataSet = new DataSet();
awConnection.Open();
productAdapter.Fill(awDataSet, “ValoresEjemplo”);
IDictionary currentStatistics = awConnection.RetrieveStatistics();
Console.WriteLine(“Total Counters: ” + currentStatistics.Count.ToString());
Console.WriteLine();
long bytesReceived = (long)currentStatistics[“BytesReceived”];
long bytesSent = (long)currentStatistics[“BytesSent”];
long selectCount = (long)currentStatistics[“SelectCount”];
long selectRows = (long)currentStatistics[“SelectRows”];
long ExecutionTime = (long)currentStatistics[“ExecutionTime”];
long ConnectionTime = (long)currentStatistics[“ConnectionTime”];
Console.WriteLine(“BytesReceived: ” + bytesReceived.ToString());
Console.WriteLine(“BytesSent: ” + bytesSent.ToString());
Console.WriteLine(“SelectCount: ” + selectCount.ToString());
Console.WriteLine(“SelectRows: ” + selectRows.ToString());
Console.WriteLine(“ExecutionTime: ” + ExecutionTime.ToString());
- The execution and connection time ( first time ) the query took:
- Without SQL Auditing enabled.
- Execution Time: 312 ms.
- Connection Time: 187 ms.
- With SQL Auditing enabled and automatic redirection:
- Execution Time: 600 ms.
- Connection Time: 234 ms
- With SQL Auditing enabled, but changing in the connection string adding the word secure, for example, <servername>.database.secure.windows.net:
- Execution Time: 482 ms.
- Connection Time: 234 ms.
- Without SQL Auditing enabled.
Some data providers don’t have implemented redirection feature.
Please, review that the data client that you are using implements TDS 7.4. If not, for example JDBC 4.0 is not fully supported and Tedious for Node.JS you have to use the FQDN: <server name>.database.secure.windows.net