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.
Table of contents
Why it is important to assess SQL*Net latency for ODB@AWS migrationsMethodology overviewMethodology deep divePhase 1: AWR screening (identify candidate SQL statements)Phase 2: SQL Execution Session Density (SESD)Phase 3: SQL Trace + CRET analysisWorked examples: CRET analysis outputPutting it all togetherInterpretation guidanceConnectivity and deployment considerations for ODB@AWS candidatesConclusionAbout the authorsQuestions 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.