Simone Greci’s blog https://docs.microsoft.com/archive/blogs/simgreci/feed.xml Data Insights PFE but also a passionate rock climber and skier. Wed, 17 Apr 2019 04:12:09 GMT en-US hourly 1 SQLServer Resolution Protocol Packets Anatomy https://docs.microsoft.com/archive/blogs/simgreci/ssrp-packets-anatomy Wed, 13 Jul 2016 18:55:49 GMT https://blogs.technet.microsoft.com/simgreci/?p=115 defined by Microsoft and introduced long time ago with SQLServer 2000 to support multiple engine instances installations on the same server. SQLServer client libraries leverages on SSRP to make easier find SQLServer in the network (using packet broadcasting/multicasting) and connect to a SQLServer Named or Clustered Istance endpoint trasparently. SSRP is an application-layer protocol (OSI's stack Level 7) based on request/response UDP packets, 1434 port is assigned by Internationl Standards. It does not provide or support security, authentication and negotiation. SSRP can be used to discover a single-istance SQLServer endpoint: image1 or multiple-istances SQLServer endpoints (broadcast/multicast): image2 SSRP communications are implemented by a client and a server: usually the client is a SQLServer client library like ADO.NET or JDBC and the server is a Database Server Discovery Service, commonly implemented in the SQLServer Broswer process (sqlbrowser.exe).

How it works SSRP?

It's quite straightforward: SQLServer Browser open a socket and listen on 1434 UDP port, clients send different types of UDP packets asking for SQLServer istances connection protocol information and the SQLBrowser reply or not with a specific UDP packet. SQLServer Browser read data about SQLServer istances configuration from registry hive. Let's see what are the UDP packets allowed by SSRP and dissect them. My bisturi is Microsoft Network Monitor that's able to understand and make human readable SSRP packets. Just set Windows Parser Profile active in the options menu: image4 Start a network trace, type ssrp on the filter and apply to catch only SSRP messages: image3  

Broadcast

Broadcast feature is used, for example, by SQLServer Management Studio to discover SQLServer istances on the network: image4 A 1 byte UDP packet CLNT_BCAST_EX is broadcasted to 255.255.255.255 ipv4 address: image6 SQLServer Browser listening on 1434 UDP port catch this message and reply with a variable lenght SVR_RESP message containing the list of available istances and and their network protocol connection information: image7 In the example above the response data contains only information about istance TCP/IP endpoint because is the only communication protocol configured on that istance, but SSRP support sending connection informations also for VIA (discontinued on 2012) and Named Pipes. Enabling Named Pipes on my SQLServer 2016 test istance the response data contained in the SVR_RESP packet is slightly different: image81

Named Instance resolution

SSRP is behind the automatic resolution of TCP port for named istances and is widely used by all SQLServer client libraries. In the example below Management Studio is connecting to a named instance called INST2016: image101 The client message involved in this mechanism is CLNT_UCAST_INST. When a SQLServer client library try to open a connection to a named istance first send a variable lenght CLNT_UCAST_INST message to resolve TCP port: image91 The SQLServer Browser reply always with a SVR_RESP message and act with the same behavior explained before.

Named Istance and DAC

DAC is the acronym for Dedicated Administrator Console and it's configured to listen on 1434 TCP port for default SQLServer installations. SSRP support port resolution also for DAC with a couple of UDP packets. As documented on technet: "...the DAC avoids using a SQL Server Resolution Protocol (SSRP) request to the SQL Server Browser Service when connecting. It first connects over TCP port 1434. If that fails, it makes an SSRP call to get the port." This is the case when DAC is not listening on standard 1434 TCP port, from SQLServer Error Log: image102 Connect using the admin prefix using SQLServer Management Studio: image103 The client send a variable lenght CLNT_UCAST_DAC message, containing the instance name: image104 The SQLBrowser reply with a SVR_RES_DAC message: image105 The right DAC TCP port is inside the response data and of course match with the Error Log entry above.]]> SQLServer 2016 AlwaysOn and new Log Transport behavior https://docs.microsoft.com/archive/blogs/simgreci/sqlserver-2016-alwayson-and-new-log-transport-behavior Fri, 17 Jun 2016 16:32:17 GMT https://blogs.technet.microsoft.com/simgreci/?p=45
  • SQLServer 2016 RTM on Windows Server 2012 R2 (local Hyper-V lab).
  • Availability Group configured in Synchronous Replication, Automatic Failover and Automatic Seeding.
    • I added a database to the Availability Group and made some tests with HammerDB, an open source benchmark utility to simulate a consistent read/write workload based on TPC-C standard. During the test I registered on PerfMon the following performance counter objects on the primary replica:
    • Databases\Log Bytes Flushed/sec
    • Availability Replica\Bytes Sent to Replica/sec
    In my environment with SQLServer 2016 what I can see is that Bytes Sent to Replica/sec is basically the same as Log Bytes Flushed/sec, looks like no compression is done: pic1 But according to this MSDN Blog article (actually for SQLServer 2012): “... besides encrypting the data which goes over the network to secondary replicas, SQL server also compress the data sent to the replicas in order to reduce network bandwidth requirements. In our example case we saw the following values:
    • Bytes Sent to Replica/sec for one specific replica: 850KB/sec
    • Log Bytes Flushed/sec for the only database in the AG: 1950KB/sec
    • Means all in all we are looking into a compression rate of around 2.3”
    The same test with HammerDB utility has been done also on SQLServer 2014 SP1 (12.0.4100.1) on Windows Server 2012 R2 and I got expected results: pic2 With SQLServer 2014 compression is done on the log transport, Log Bytes flushed to transaction log are twice the Bytes sent to replicas. But why not on the new SQLServer version? The reason for this difference is that defaults for AlwaysOn log transport compression are changed on SQLServer 2016:
    1. Log stream compression is disabled by default for Sync replicas to ensure sync replication does not slow down OLTP relative to standalone. Compression adds latency, hence off by default. Flip it by using -T9592.
    2. Log stream compression is enabled by default for Async replicas to reduce ingress\egress costs for geo replication so compression is enabled by default for async. Flip it by using -T1462.
    3. Compression is disabled by default for Automatic Seeding to reduce CPU usage on primary. Flip it by using -T9567.
    New trace flags will be on MSDN soon, stay tuned.      ]]>