<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Execution breakdown &amp;quot;Other&amp;quot; paired with SQL contention on the database SQL connection in Extensions</title>
    <link>https://community.dynatrace.com/t5/Extensions/Execution-breakdown-quot-Other-quot-paired-with-SQL-contention/m-p/296394#M7144</link>
    <description>&lt;P&gt;Hi everyone,&lt;/P&gt;&lt;P&gt;For a customer we have a situation where we can see lots of latches waiting and a high average wait time in the metrics coming from the MSSQL extension (remote).&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="Afbeelding1.png" style="width: 624px;"&gt;&lt;img src="https://community.dynatrace.com/t5/image/serverpage/image-id/32397i71791D2926E484B0/image-size/large?v=v2&amp;amp;px=999" role="button" title="Afbeelding1.png" alt="Afbeelding1.png" /&gt;&lt;/span&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;A trace that was executed specifically during the peak at 08:46 shows fast queries, but is still waiting a long time until the request is processed.&lt;/P&gt;&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="Screenshot 2026-03-19 103530.jpg" style="width: 623px;"&gt;&lt;img src="https://community.dynatrace.com/t5/image/serverpage/image-id/32398iF809E9C578FB526E/image-size/large?v=v2&amp;amp;px=999" role="button" title="Screenshot 2026-03-19 103530.jpg" alt="Screenshot 2026-03-19 103530.jpg" /&gt;&lt;/span&gt;&lt;/P&gt;&lt;P&gt;In the new tracing app, Dynatrace shows the message "Elapsed time from the start of the first span to the end of the last span."&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;In the distributed traces classic app is this long timing categorized as "Other".&lt;/P&gt;&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="image (15).png" style="width: 272px;"&gt;&lt;img src="https://community.dynatrace.com/t5/image/serverpage/image-id/32399i0C492669E6DC1F51/image-size/large?v=v2&amp;amp;px=999" role="button" title="image (15).png" alt="image (15).png" /&gt;&lt;/span&gt;&lt;/P&gt;&lt;P&gt;We have identified that the database is a lot of latches waiting a long time on resources in general and that there is response time issues for queries caused by contention of shared resources within the SQL server.&lt;/P&gt;&lt;P&gt;My question is, could it be that Dynatrace sees these these long response times on the middelware as 'Other' timings, because the SQL server is waiting internally and the client waits on the SQL response, so the delay is not falling under any of these categories like CPU or network IO?&lt;/P&gt;</description>
    <pubDate>Thu, 19 Mar 2026 09:48:11 GMT</pubDate>
    <dc:creator>nils_stellhorn</dc:creator>
    <dc:date>2026-03-19T09:48:11Z</dc:date>
    <item>
      <title>Execution breakdown "Other" paired with SQL contention on the database SQL connection</title>
      <link>https://community.dynatrace.com/t5/Extensions/Execution-breakdown-quot-Other-quot-paired-with-SQL-contention/m-p/296394#M7144</link>
      <description>&lt;P&gt;Hi everyone,&lt;/P&gt;&lt;P&gt;For a customer we have a situation where we can see lots of latches waiting and a high average wait time in the metrics coming from the MSSQL extension (remote).&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="Afbeelding1.png" style="width: 624px;"&gt;&lt;img src="https://community.dynatrace.com/t5/image/serverpage/image-id/32397i71791D2926E484B0/image-size/large?v=v2&amp;amp;px=999" role="button" title="Afbeelding1.png" alt="Afbeelding1.png" /&gt;&lt;/span&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;A trace that was executed specifically during the peak at 08:46 shows fast queries, but is still waiting a long time until the request is processed.&lt;/P&gt;&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="Screenshot 2026-03-19 103530.jpg" style="width: 623px;"&gt;&lt;img src="https://community.dynatrace.com/t5/image/serverpage/image-id/32398iF809E9C578FB526E/image-size/large?v=v2&amp;amp;px=999" role="button" title="Screenshot 2026-03-19 103530.jpg" alt="Screenshot 2026-03-19 103530.jpg" /&gt;&lt;/span&gt;&lt;/P&gt;&lt;P&gt;In the new tracing app, Dynatrace shows the message "Elapsed time from the start of the first span to the end of the last span."&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;In the distributed traces classic app is this long timing categorized as "Other".&lt;/P&gt;&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="image (15).png" style="width: 272px;"&gt;&lt;img src="https://community.dynatrace.com/t5/image/serverpage/image-id/32399i0C492669E6DC1F51/image-size/large?v=v2&amp;amp;px=999" role="button" title="image (15).png" alt="image (15).png" /&gt;&lt;/span&gt;&lt;/P&gt;&lt;P&gt;We have identified that the database is a lot of latches waiting a long time on resources in general and that there is response time issues for queries caused by contention of shared resources within the SQL server.&lt;/P&gt;&lt;P&gt;My question is, could it be that Dynatrace sees these these long response times on the middelware as 'Other' timings, because the SQL server is waiting internally and the client waits on the SQL response, so the delay is not falling under any of these categories like CPU or network IO?&lt;/P&gt;</description>
      <pubDate>Thu, 19 Mar 2026 09:48:11 GMT</pubDate>
      <guid>https://community.dynatrace.com/t5/Extensions/Execution-breakdown-quot-Other-quot-paired-with-SQL-contention/m-p/296394#M7144</guid>
      <dc:creator>nils_stellhorn</dc:creator>
      <dc:date>2026-03-19T09:48:11Z</dc:date>
    </item>
  </channel>
</rss>

