--- title: Characterizing SQL*Net latency in your application for... description: A three-phase methodology called CRET (Client Request Elapsed Time) is presented to help teams assess whether their Oracle workloads are sensitive to SQL*Net... canonical: https://daily.dev/posts/characterizing-sql-net-latency-in-your-application-for-oracle-database-aws-migrations-qlrdm4g9o twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Characterizing SQL*Net latency in your application for Oracle Database@AWS migrations | daily.dev og:description: A three-phase methodology called CRET (Client Request Elapsed Time) is presented to help teams assess whether their Oracle workloads are sensitive to SQL*Net... og:url: https://daily.dev/posts/characterizing-sql-net-latency-in-your-application-for-oracle-database-aws-migrations-qlrdm4g9o og:image: https://api.daily.dev/og/posts/qLRdm4G9o.png og:image:alt: Characterizing SQL*Net latency in your application for Oracle Database@AWS migrations og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Characterizing SQL*Net latency in your application for Oracle Database@AWS migrations **[AWS Database Blog](https://daily.dev/sources/aws-database-blog)** · 13 min read · 0 upvotes · 0 comments ## Summary A three-phase methodology called CRET (Client Request Elapsed Time) is presented to help teams assess whether their Oracle workloads are sensitive to SQL*Net latency before migrating to Oracle Database@AWS (ODB@AWS). Phase 1 uses AWR reports to identify SQL statements with sub-millisecond database processing time and high execution frequency. Phase 2 checks SQL Execution Session Density to confirm executions are concentrated in few sessions. Phase 3 uses SQL Trace and a set of AWK one-liners to quantify projected runtime impact from added SQL*Net round-trip latency. Worked examples contrast a tight-loop trace (highly sensitive to added latency) against a client-delay trace (tolerant), and an interpretation table classifies workloads as tolerant, borderline, or sensitive based on projected percentage impact. Connectivity recommendations include co-locating application tiers with ODB Peering and enabling ODB@AWS high-performance networking for sub-millisecond round-trip latency. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How do I determine if my Oracle workload is sensitive to SQL*Net latency before migrating to Oracle Database@AWS? Use a three-phase CRET methodology: first screen AWR reports for SQL statements with sub-millisecond database processing time and thousands of executions per second, then check SQL Execution Session Density to confirm those executions come from very few sessions rather than being spread across many, and finally trace a high-density session with SQL Trace to measure the actual round-trip time and project the impact of added latency (e.g., +100μs, +150μs, +200μs). _daily.dev surfaces migration and performance guidance for teams planning Oracle Database@AWS moves._ ### What does the SQL*Net message from client (SNMFC) wait event represent in an Oracle SQL trace? SNMFC is an idle wait event marking the time the database session spends waiting for the next request from the client, covering both client-side processing and network round-trip time. Two consecutive SNMFC waits bracket a Client Request Elapsed Time (CRET) event, and the delta between their tim= values gives the total CRET duration, while the closing SNMFC ela= value gives the non-database time. _Developers diagnosing Oracle client-server latency can find deep-dive trace analysis techniques like this on daily.dev._ ### What percentage of projected runtime increase indicates a workload is not suitable for Oracle Database@AWS due to latency sensitivity? A projected impact above 10% classifies a workload as sensitive, meaning material performance degradation is expected and requires RTT characterization, mitigation, or architecture review. Impact under 5% is considered tolerant and suitable for ODB@AWS as-is, while 5-10% is borderline and warrants discussion with the application owner before deciding. _Teams weighing cloud database migration tradeoffs can track this kind of decision framework on daily.dev._ ## Similar posts on daily.dev - [SQL Server Network Latency: When the Database Isn't Slow](https://daily.dev/posts/sql-server-network-latency-when-the-database-isn-t-slow-3g2fgkcii) · SQL Authority · 0 upvotes · 0 comments - [Analyzing round trip query latency](https://daily.dev/posts/analyzing-round-trip-query-latency-nzr43a6sy) · Datadog · 0 upvotes · 0 comments - [Manage long-running transactions for AWS DMS performance](https://daily.dev/posts/manage-long-running-transactions-for-aws-dms-performance-bdgogkizz) · AWS Database Blog · 0 upvotes · 0 comments - [How to turn slow queries into actionable reliability metrics with OpenTelemetry](https://daily.dev/posts/how-to-turn-slow-queries-into-actionable-reliability-metrics-with-opentelemetry-5crln7qq6) · CNCF · 0 upvotes · 0 comments --- Tags: [#aws](https://daily.dev/tags/aws), [#database](https://daily.dev/tags/database), [#oracle](https://daily.dev/tags/oracle) [View this post on daily.dev](https://daily.dev/posts/characterizing-sql-net-latency-in-your-application-for-oracle-database-aws-migrations-qlrdm4g9o) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Characterizing SQL*Net latency in your application for Oracle Database@AWS migrations","url":"https://daily.dev/posts/characterizing-sql-net-latency-in-your-application-for-oracle-database-aws-migrations-qlrdm4g9o","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/characterizing-sql-net-latency-in-your-application-for-oracle-database-aws-migrations-qlrdm4g9o"},"datePublished":"2026-08-18T18:22:47.634Z","dateModified":"2026-08-18T18:41:12.885Z","description":"A three-phase methodology called CRET (Client Request Elapsed Time) is presented to help teams assess whether their Oracle workloads are sensitive to SQL*Net...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/c89dfbfc882dc4a7f3bd25098851850e?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/c89dfbfc882dc4a7f3bd25098851850e?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"AWS Database Blog","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"AWS Database Blog","logo":"https://media.daily.dev/image/upload/s--En-avd2a--/f_auto,q_auto/v1780213446/logos/aws-database-blog?_a=BAMAMiWQ0","url":"https://daily.dev/sources/aws-database-blog"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/characterizing-sql-net-latency-in-your-application-for-oracle-database-aws-migrations-qlrdm4g9o","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"aws,database,oracle","timeRequired":"PT13M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"AWS Database Blog","item":"https://daily.dev/sources/aws-database-blog"},{"@type":"ListItem","position":3,"name":"Characterizing SQL*Net latency in your application for Oracle Database@AWS migrations"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/characterizing-sql-net-latency-in-your-application-for-oracle-database-aws-migrations-qlrdm4g9o#faq","mainEntity":[{"@type":"Question","name":"How do I determine if my Oracle workload is sensitive to SQL*Net latency before migrating to Oracle Database@AWS?","acceptedAnswer":{"@type":"Answer","text":"Use a three-phase CRET methodology: first screen AWR reports for SQL statements with sub-millisecond database processing time and thousands of executions per second, then check SQL Execution Session Density to confirm those executions come from very few sessions rather than being spread across many, and finally trace a high-density session with SQL Trace to measure the actual round-trip time and project the impact of added latency (e.g., +100μs, +150μs, +200μs). daily.dev surfaces migration and performance guidance for teams planning Oracle Database@AWS moves."}},{"@type":"Question","name":"What does the SQL*Net message from client (SNMFC) wait event represent in an Oracle SQL trace?","acceptedAnswer":{"@type":"Answer","text":"SNMFC is an idle wait event marking the time the database session spends waiting for the next request from the client, covering both client-side processing and network round-trip time. Two consecutive SNMFC waits bracket a Client Request Elapsed Time (CRET) event, and the delta between their tim= values gives the total CRET duration, while the closing SNMFC ela= value gives the non-database time. Developers diagnosing Oracle client-server latency can find deep-dive trace analysis techniques like this on daily.dev."}},{"@type":"Question","name":"What percentage of projected runtime increase indicates a workload is not suitable for Oracle Database@AWS due to latency sensitivity?","acceptedAnswer":{"@type":"Answer","text":"A projected impact above 10% classifies a workload as sensitive, meaning material performance degradation is expected and requires RTT characterization, mitigation, or architecture review. Impact under 5% is considered tolerant and suitable for ODB@AWS as-is, while 5-10% is borderline and warrants discussion with the application owner before deciding. Teams weighing cloud database migration tradeoffs can track this kind of decision framework on daily.dev."}}]} ```