SQL Monitor (SQLM) and SQL Performance Tuning Worklist (SWLT)

A focused ST05 trace is excellent for one reproduction but cannot easily answer which custom SQL statements matter across days of productive usage. SQL Monitor collects aggregated statistics for SQL statements executed while monitoring is active, including caller/source context and counts/runtime measures depending on release. SWLT consumes runtime information and static code-analysis findings to build a worklist of candidates whose technical issue is both detectable and actually used. This is particularly useful in S/4HANA migration/performance programs where thousands of static findings exist but only a subset are hot in production.

Use SQLM when you need workload evidence over time rather than one user trace: repeated expensive statements, SQL called millions of times, custom objects that are actually executed, or before/after monitoring during tuning. Use SWLT to prioritize remediation based on static issue plus dynamic execution relevance. Do not leave monitoring active without operational planning on very high-volume systems; choose scope/duration appropriate to the goal and follow system guidance.

SQLM complements ATC/Code Inspector, SCMON/usage data, ST05 and SAT. ATC can say code pattern X is risky; SQLM can say whether it actually runs and how often. SWLT brings those views together for prioritization. HANA DB tools show server-side expensive statements, but SQLM's ABAP source attribution is valuable for finding the custom source position responsible. Custom Code Migration apps use similar evidence-driven principles for S/4HANA remediation.

A conversion program produces 20,000 ATC SQL findings. Rather than treating all equally, the team enables SQL monitoring for a representative business period, then uses SWLT to focus on frequently executed custom statements with high runtime and known static issues. A rarely executed month-end utility is scheduled later, while an inefficient SELECT inside a transaction used thousands of times daily is fixed first. This turns a theoretical backlog into a business-relevant performance plan.

SQLM/SWLT are particularly valuable in S/4HANA custom-code optimization and conversion projects because the objective is not only syntax compatibility but productive workload efficiency. HANA simplifies some access paths while making set-oriented design and high-frequency round trips more visible. Availability and exact UI/tooling vary by ABAP platform release and cloud deployment.

Performance/ABAP teams operate the analysis, Basis coordinates productive monitoring windows, and application owners confirm representative workloads. Program owners fix and retest the high-priority candidates. Architecture/governance teams can use results to enforce evidence-based modernization rather than blanket rewrites.

ST05/SAT/ST12 are focused trace tools; ATC checks provide static findings; the Custom Code Migration and ABAP SQL performance technical topics explain how SQLM evidence feeds S/4HANA remediation.

Production verification: Capture program and source line, selection or variant, realistic data volume, execution count, transferred rows, elapsed and database time, and the before and after trace. Use ST05 or SQLM for SQL evidence and SAT or ST12 for application runtime; optimize query shape and call frequency before changing indexes or adding parallelism.

Operational readiness: For production readiness of SQL Monitor (SQLM) and SQL Performance Tuning Worklist (SWLT), add one reproducible test case with realistic data volume and boundary values, one negative test that proves the failure contract, and one operational check that a support developer can run without changing productive data. Record the exact program, class or function and any release-dependent API assumptions. Where the topic affects performance or transaction consistency, compare evidence before and after the change instead of relying on coding folklore or one sandbox execution.