MENU

 SEARCH LOG IN REGISTER

RECENT

EdgeX Foundry Brings an Ecosystem

Ethos to the Edge
MAY 03, 2019

A Collision Course: AI Marketing, People

and Process
MAY 02, 2019

Microsoft Announces HoloLens 2

Developer Edition Ahead of Build
MAY 02, 2019
DATA ANALYTICS AND DATA MANAGEMENT > SQL SERVER

Facebook Wants AI to Screen Content,

But Fairness Issues Remain SQL Server TCP and UDP Ports
MAY 01, 2019

A handy list of what's what

How Data Centers Can Use the New
Smart Cybersecurity Tools
Michael Otey | Apr 15, 2014
MAY 01, 2019

     
FEATURED

Microsoft Unveils Azure Backup for SQL SQL Server has evolved from a simple relational database engine to a multipurpose
Server
enterprise-level data platform. The subsystems and features that Microsoft has added—and
MAR 21, 2019
continues to add—to SQL Server have significantly increased the network connections that
the platform uses. Sometime it's tricky to figure out which firewall ports to open for each
Real-Time Threat Intelligence Service
Aims to Shut Down Phishing
This websiteSQL
uses cookies,
Server including third party
feature. ones, to
To help allowhere's
you, for analysis of how peopleof
a rundown use
commonly × used SQL Server network
our website in order to improve your experience and our services. By continuing to use our
MAR 19, 2019 ports.
website, you agree to the use of such cookies. Click here for more information on our Cookie
Policy and Privacy Policy.

Tips for Securing Windows XP (Yes, Win TCP 1433

XP)
MAR 17, 2019
TCP port 1433 is the default port for SQL Server. This port is also the official Internet
Assigned Number Authority (IANA) socket number for SQL Server. Client systems use TCP
What You Need to Know about
1433 to connect to the database engine; SQL Server Management Studio (SSMS) uses the
Windows Storage Spaces Direct
MAR 24, 2019 port to manage SQL Server instances across the network. You can reconfigure SQL Server to
listen on a different port, but 1433 is by far the most common implementation.

TCP 1434

TCP port 1434 is the default port for the Dedicated Admin Connection. You can start the
Dedicated Admin Connection through sqlcmd or by typing ADMIN: followed by the server
name in the SSMS Connect to Database Engine dialog box.

UDP 1434

UDP port 1434 is used for SQL Server named instances. The SQL Server Browser service
listens on this port for incoming connections to a named instance. The service then
responds to the client with the TCP port number for the requested named instance.

TCP 2383

TCP port 2383 is the default port for SQL Server Analysis Services.

TCP 2382

TCP port 2382 is used for connection requests to a named instance of Analysis Services.
Much like the SQL Server Browser service does for the relational database engine on UDP
1434, the SQL Server Browser listens on TCP 2382 for requests for Analysis Services named
instances. Analysis Services then redirects the request to the appropriate port for the named
instance.

TCP 135

TCP port 135 has several uses. The Transact-SQL debugger uses the port. TCP 135 is also
used to start, stop, and control SQL Server Integration Services, although it is required only
if you connect to a remote instance of the service from SSMS.

TCP 80 and 443

TCP ports 80 and 443 are most typically used for report server access. However, they also
support URL requests to SQL Server and Analysis Services. TCP 80 is the standard port for
HTTP connections that use a URL. TCP 443 is used for HTTPS connections that use secure
sockets layer (SSL).

Uno cial TCP Ports

Microsoft uses TCP port 4022 for SQL Server Service Broker examples in SQL Server Books
Online. Likewise, BOL Database Mirroring examples use TCP port 7022.

This summary should cover your most pressing port needs. You can find more detailed
information about the TCP and UDP ports that SQL Server uses in the Microsoft article
"Configure the Windows Firewall to Allow SQL Server Access."

0 COMMENTS

RELATED

Free Microsoft Training Is as Close as Your Getting Started with Azure Data Studio and
Mobile Device SQL Server 2019 Preview
MAY 01, 2019 MAR 28, 2019

How to Prepare for SQL Server 2008 and Examining Scalar Function Performance in
2008 R2 End of Support SQL Server
MAR 28, 2019 FEB 24, 2019

DATA ANALYTICS AND DATA MANAGEMENT > SQL SERVER

Examining Scalar Function

Performance in SQL Server
Each new release of SQL Server brings new DMOs. This
article digs into dm_exec_function_stats, which made its
debut in Microsoft SQL Server 2016.

Tim Ford | Feb 24, 2019

     

Microsoft SQL Server provides a number of ways for data professionals to glean knowledge
of the inner workings of the platform: From Dynamic Management Views (DMVs) and
Functions (DMFs) to Extended Events, Catalog Views and an endless supply of third-party
tools, you can find out pretty much anything about the internals of SQL Server if you know
where to look.

I’ve written extensively about Dynamic Management Objects (DMOs), and each new release
of SQL Server brings with it new DMOs. The one we’re focusing on today has been around
since Microsoft SQL Server 2016: dm_exec_function_stats.

dm_exec_function_stats is similar in output to two other DMVs:

dm_exec_procedure_stats and dm_exec_query_stats. Each provides metrics on
performance for specific object types in cache: dm_exec_function_stats (user-defined
functions), dm_exec_procedure_stats (non-system stored procedures) and
dm_exec_query_stats (user generated queries).

dm_exec_function_stats provides more granular performance analysis than

dm_exec_procedure_stats and dm_exec_query_stats. While procedure_stats and
query_stats provide metadata around CPU, RAM, I/O and duration information around the
complete execution of a stored procedure or query, function_stats does so for a user-defined
function, which is never a stand-alone object. You must use a function inside of a statement.
That statement by itself, or in concert with other T-SQL commands, will then be part of
either a stored procedure or an ad-hoc query. This means that using
dm_exec_function_stats allows us to drill into performance of a function. Using
dm_exec_procedure_stats and dm_exec_query_stats includes all T-SQL that is part of
those units (stored procedures or batches of ad-hoc t-sql), which may include one or more
user-defined functions (UDFs).

As is the case with its cousins, dm_exec_function_stats has a significant number of output
columns that cover the classes of key indicators you’d expect when performance tuning
items in SQL Server:

• CPU: min, max and last execution’s results

• RAM: min, max and last execution’s results
• Duration: min, max and last execution’s results
• I/O: Logical and physical reads; physical writes: min, max and last execution’s results
• Execution count
• SQL Handle: uniquely identifying the T-SQL text that makes up the function’s
definition
• Plan Handle: identifies the query plan cached for the function
• Identifying information such as database_id and object_id, type

The existence of sql_handle and plan_handle in this DMV allows you to join to other DMOs
to return the defining code for the function and see the graphical execution plan. You can
also use system functions like dm_name() and object_name() to make columns such as
database_id and object_id more user-friendly when looking at results.

Take, for example, the following query to look at the state of user-defined scalar functions
for a given instance/database sorted by duration. By default, this query returns results for
the currently in-scope database through the WHERE clause I’ve coded:

SELECT TOP 25 db_name(eST.[dbid]) AS [database]

, OBJECT_SCHEMA_NAME(eFS.[object_id], eFS.database_id) AS [schema_name]

, OBJECT_NAME(eFS.[object_id], eFS.database_id) AS [function_name]

, eFS.execution_count

-- CPU

, CAST(eFS.min_worker_time/1000.0 AS decimal(16,4)) AS [min_cpu_time_mcs]

, CAST(eFS.max_worker_time/1000.0 AS decimal(16,4)) AS [max_cpu_time_mcs]

, CAST(eFS.total_worker_time/(ISNULL(eFS.execution_count, 1.0)) AS decimal(16,4))

-- ELAPSED TIME

, CAST( eFS.min_elapsed_time/1000.0 AS decimal(16,4)) AS [min_duration_mcs]

, CAST(eFS.max_elapsed_time/1000.0 AS decimal(16,4)) AS [max_duration_mcs]

, CAST(eFS.total_elapsed_time/(ISNULL(eFS.execution_count, 1.0)) AS decimal(16,4)

-- LOGICAL READS

, eFS.min_logical_reads AS [min_logical_reads]

, eFS.max_logical_reads AS [max_logical_reads]

, eFS.total_logical_reads/ISNULL(eFS.execution_count, 1) AS [avg_logical_reads]

-- PHYSICAL READS

, eFS.min_physical_reads AS [min_physical_reads]

, eFS.max_physical_reads AS [max_physical_reads]

, eFS.total_physical_reads/ISNULL(eFS.execution_count, 1) AS [avg_physical_reads]

-- LOGICAL WRITES

, eFS.min_logical_writes AS [min_writes]

, eFS.max_logical_writes AS [max_writes]

, eFS.total_logical_writes/ISNULL(eFS.execution_count, 1) AS [avg_writes]

-- CACHE & EXEC TIMES

, eFS.last_execution_time

--STATEMENTS AND QUERY TEXT DETAILS

, eST.text AS [procedure_code]

, eFS.[plan_handle]

FROM sys.dm_exec_function_stats AS eFS

CROSS APPLY sys.dm_exec_sql_text(eFS.sql_handle) AS eST

CROSS APPLY sys.dm_exec_query_plan (eFS.plan_handle) AS eQP

WHERE eST.[dbid] = db_id()

--ORDER BY eFS.total_logical_reads/ISNULL(eFS.execution_count, 1) DESC; -- [avg_l

--ORDER BY eFS.total_physical_reads/ISNULL(eFS.execution_count, 1) DESC; -- [avg_p

--ORDER BY eFS.total_logical_writes/ISNULL(eFS.execution_count, 1) DESC; -- [avg_l

ORDER BY eFS.total_worker_time/ISNULL(eFS.execution_count, 1) DESC; -- [avg_c

--ORDER BY eFS.total_elapsed_time/ISNULL(eFS.execution_count, 1) DESC; -- [avg_d

I’ve broken the results up here into logical “chunks” and also to make what is a wide result
set easier to read:

The query is easily adjustable to focus on just those functions you’re interested in based on
the options for sorting by duration, reads, writes, CPU, etc., depending on which line you
choose to uncomment in the ORDER BY clause.

Another thing to consider when looking at the results that come from these DMOs is the
unit of measure that is appropriate. You’re not likely to measure a garage in millimeters to
see if your new car is going to fit. You’re likely going to use a unit of measure more
appropriate for the job. The same goes with functions compared to procedures or ad-hoc
query executions. Duration in the various columns provided by these objects is measured in
microseconds--1/1,000,000 of a second. When I’ve written queries using
dm_exec_procedure_stats and dm_exec_query_stats for analysis I’ve always reduced that
unit of measure by a factor of 1,000 to measure duration as milliseconds--1/1000 of a
second. This matches the default unit of measure for performance benchmarks for queries.
Since functions are but a component of a larger query (be it in stored procedure or ad hoc
form), I leave the unit of measure as microseconds.

In examining the results, the first thing that jumps out to me is the range of execution
duration times between the average and the max values. I’d be really curious to dig into
these results further to ascertain why performance is (possibly) inconsistent. I find this
query valuable when attempting to identify functions that may warrant tuning attention. It's
also valuable for zeroing in on performance improvements, where I’m seeing them through
my analysis of stored procedures or ad-hoc sql where functions play a role.
dm_exec_function_stats is another one of those tools to keep on hand when analyzing
performance in your Microsoft SQL Server instances.

TAGS: DATA ANALYTICS AND DATA MANAGEMENT

RELATED

What Microsoft's Open Source PostgreSQL Failover Detection Utility Simplifies

Acquisition Portends for SQL Server Availability Group Failover Analysis
FEB 10, 2019 JAN 09, 2019

Talking T-SQL (among Many Other 4 Online SQL Server Help Resources for DBAs
Enterprise SQL Server Topics) ('Accidental' and Otherwise)
DEC 31, 2018 DEC 20, 2018

Next Article

Sign up for the ITPro Update newsletter.

Email address United States SIGN UP ▸

About Ad Choices Follow us:

Advertise Privacy Policy

  

Contact Us Terms of Service

Sitemap Cookie Policy

© 2019 Informa USA, Inc., All Rights Reserved