SAP Library / Basis / Cheat sheet
SAP Basis cheat sheet
32 objects in 5 groups. Each links to its full reviewed page.
T-Codes18
- ST22ST22 is used to analyze ABAP short dumps with runtime error, call stack, source extract, user and timestamp context. It is most useful when a dialog, background, RFC or update process terminates with an ABAP runtime error. For reliable support work, start with the exact system, client, user and business context, then use the transaction's own logs or status information before changing configuration or data.
- SM21SM21 displays the kernel-level system log, which records work process starts and terminations, database connection errors, security audit events, and ABAP runtime failures at the operating system layer. It is a read-only viewer, not a database table browser. The underlying log is a rolling file per application server instance, so old entries age out and disappear once the buffer wraps.
- SM37SM37 is used to monitor scheduled background jobs, job steps, variants, logs, spool output and cancellation status. It is most useful when a scheduled report did not run, ran late, cancelled, or produced unexpected output. For reliable support work, start with the exact system, client, user and business context, then use the transaction's own logs or status information before changing configuration or data.
- SM50SM50 displays the work processes (dialog, background, update, enqueue, spool) running on the application server instance the user is currently logged onto, showing status, user, program, table accessed and elapsed time. It is instance-local, not system-wide; use SM66 to see work processes across all application servers in the cluster.
- SM66SM66 lists the work processes running on every application server in the system, gathered live via RFC calls from each instance rather than read from a database table. It is used to find a hung, long-running, or resource-hogging process anywhere in a multi-server landscape when the local-server view in SM50 is not enough.
- SM12SM12 is used to display and, with care, delete SAP enqueue locks that protect business objects from conflicting updates. It is most useful when users receive object-locked messages, stale locks remain after failures, or an update cannot acquire an enqueue lock. For reliable support work, start with the exact system, client, user and business context, then use the transaction's own logs or status information before changing configuration or data.
- SM13SM13 shows the queue of asynchronous database update requests generated by SAP's update task mechanism. It is used when a user reports a document as saved that never actually posted downstream, letting a consultant see whether the update terminated with an error, inspect the failing function module, and reprocess or delete the request once the root cause is understood.
- SM59SM59 maintains RFC destinations, the stored connection parameters (target host, system, client, logon data) that let one SAP system call another system, an external program, or an HTTP service. A green connection test proves the network path and stored credentials work; it does not prove the actual interface call, which may use a different destination, user, or timeout, will succeed.
- SICFSICF maintains the ICF service tree - the hierarchy of HTTP/HTTPS services (Fiori apps, OData endpoints, SOAP/REST services, ICF-based web services) that the Internet Communication Manager routes requests to. Activation is inherited down the tree, so a node showing active can still return 404 or 403 if a parent node above it in the path is inactive, wrongly authorized, or missing its handler class.
- SMICMSMICM is the monitor for the Internet Communication Manager, the OS-level process that handles inbound and outbound HTTP, HTTPS, and SMTP traffic for the ABAP stack. It shows whether ICM is running, which services and ports are active, connection and thread usage, and SSL/PSE status. It has no persistent business data of its own; everything shown is live process state plus profile parameters and trace files.
- ST03NST03N is used to analyze aggregated ABAP system workload by instance, task type, transaction, user and response-time components. It is most useful when Basis or performance teams need to identify where system response time is being spent over a selected period. For reliable SAP support, capture the exact system, client, user, time and object context first, then use the transaction's evidence before making configuration or data changes.
- ST04ST04 is the database performance monitor, showing CPU, memory, disk, wait events and expensive SQL statements for the connected database. On classic databases (Oracle, DB2) the screens are generated by database-specific function modules; on HANA it becomes a HANA-specific monitor overlapping heavily with DBA Cockpit, which is why the transaction looks completely different depending on the underlying database.
- ST06ST06 is the operating system monitor for the application server host currently logged onto. It shows CPU utilization, memory and paging, disk I/O, and LAN statistics collected by the saposcol daemon running at OS level, not inside the ABAP stack. It is the first stop when performance complaints might be a hardware or OS bottleneck rather than ABAP or database.
- RZ10RZ10 maintains the default, instance and start profiles that control kernel and work process behavior on an SAP system. It edits and activates a database-tracked version of the profile, but the change only takes effect for a running instance after restart, unless the specific parameter is flagged as dynamically switchable, in which case RZ11 applies it immediately.
- RZ11RZ11 displays and, for dynamically switchable parameters, changes an ABAP system profile parameter at runtime without a restart. It shows current value, profile value, default value, and documentation. Changes made here live only in instance memory until the same value is also set in the profile through RZ10 - otherwise the change disappears on the next restart.
- STMSSTMS is the transaction that configures the transport domain, maintains transport routes between systems in a landscape, and runs the import queue that brings transport requests into a target system. It does not create or release requests itself; that happens in SE09 or SE10. STMS sits on top of the OS-level tp program and reads the transport buffer, not a simple database table.
- SNOTESNOTE is used to download, analyze and implement applicable SAP Notes while tracking prerequisites and correction instructions. It is most useful when SAP support guidance requires a Note implementation or when checking whether a correction is already present in the system. For reliable support work, start with the exact system, client, user and business context, then use the transaction's own logs or status information before changing configuration or data.
- SPAMSPAM is used to import and monitor ABAP Support Packages and related support package queues. It is most useful during planned maintenance of ABAP-based SAP systems where support package stacks are applied. For reliable support work, start with the exact system, client, user and business context, then use the transaction's own logs or status information before changing configuration or data.
Key Tables5
- TBTCOTBTCO holds one row per background job instance: job name, job number (JOBCOUNT), status code, scheduled versus actual start and end timestamps, the authorization user, and event or periodic flags. It does not hold job steps, print parameters, or spool content — those live in TBTCP, TBTCS, and TSP01/TSP03. Use it to prove when a job ran, how long it ran, and what status it ended in.
- TBTCPTBTCP stores one row per step of a background job: the program or external command, the variant, the step sequence number, and the user under whose authorization the step runs. It is the child table of TBTCO, the job header. It holds what is scheduled to execute, not runtime status or duration, which live in TBTCO and the job log.
- TSP01TSP01 is the header table for spool requests. Each row represents one spool request created in the system, whether from a background job step, an online print, or an ABAP list, and carries the owner, creation timestamp, title, status, page count and target output device. It does not hold the actual print data, only its metadata.
- BALHDRBALHDR stores one row per application log header created through the SBAL application log framework (transactions SLG0, SLG1, SLG2). Each row records the log's object and subobject classification, external number, creation date, time, user, program, and transaction code, plus a planned deletion date. It does not contain the log message text itself, which is serialized separately in BALDAT.
- BALDATBALDAT holds the serialized message and context data belonging to an application log header created via the SBAL application log framework (SLG1/SLG2). Each row is a packed data chunk keyed by LOGNUMBER, the same key used in BALHDR. It cannot be read meaningfully through SE16N; message content must be retrieved through the application log API or SLG1 display.
Key Concepts4
- SAP AS ABAP Work Processes and Dispatcher ArchitectureIn an ABAP application server instance, the dispatcher receives requests and assigns them to available work processes. Dialog work processes execute interactive ABAP steps, background work processes run scheduled jobs, update work processes execute deferred updates, and spool work processes prepare output. Modern systems provide enqueue as a central service in the ASCS rather than treating it as an ordinary work process on every application server.
- SAP Background Jobs: SM36/SM37, Steps, Events and SchedulingA classic SAP background job has a header/schedule definition in TBTCO and one or more executable steps in TBTCP, such as ABAP programs/variants or external commands. SM36 schedules jobs and SM37 monitors execution. Jobs can start by date/time, event, predecessor or other conditions depending on release. Success means the scheduler/work process completed the job step; business success still depends on the program's own messages/logs.
- SAP Transport Requests: Workbench, Customizing and Transport of CopiesWorkbench requests transport repository and cross-client development objects, Customizing requests transport client-dependent configuration recorded by Customizing, and Transport of Copies sends selected objects to a target without becoming the normal consolidation request in the landscape route. The request type follows the object/change category and transport strategy; choosing the wrong type can create missing dependencies, client surprises or poor traceability.
- SAP Profile Parameters: RZ10, RZ11 and Dynamic ChangesSAP profile parameters control ABAP instance and system runtime behavior such as work-process counts, memory limits, timeouts and communication settings. RZ11 displays parameter documentation and current/default values and can change only dynamically switchable parameters at runtime. RZ10 maintains persistent profile configuration. A dynamic RZ11 change is not a substitute for updating the appropriate persistent profile when the value must survive restart.
HANA Essentials3
- SAP HANA Row Store vs Column StoreSAP HANA supports row-store and column-store tables. Row store keeps complete rows together and can suit very small metadata tables or highly row-oriented access, while column store stores each column separately with dictionary encoding and compression, enabling efficient scans, aggregation and vectorized processing over large datasets. S/4HANA business persistence is predominantly column-store; changing table store type should follow SAP/data-model guidance, not generic tuning folklore.
- SAP HANA Delta Merge ExplainedHANA column tables separate a compressed read-optimized main store from write-optimized delta storage. Inserts and many changes accumulate in delta structures; a delta merge consolidates committed delta data into a new compressed main store and releases obsolete structures when safe. HANA triggers merges automatically based on internal criteria. Frequent forced manual merges usually indicate misunderstanding or a workload/design issue rather than routine administration.
- SAP HANA PlanViz and SQL Analyzer for Performance DiagnosisHANA execution-plan analysis shows how the database actually executes a SQL statement: operators, joins, filters, cardinalities, data movement, parallelism and time or memory hotspots. PlanViz visualizes detailed runtime plans in HANA tooling, while SQL Analyzer/cockpit tools provide modern statement-plan analysis depending on HANA version. Use them after identifying a costly statement with ST05, SQLM or HANA expensive-statement monitoring.
Fiori Operations2
- Fiori app troubleshooting when a tile does not appearA missing tile almost always means a break in the chain between launchpad content and authorization, not a broken app. Check, in order: role assignment to the user, catalog or business catalog assignment to that role, group or space/page assignment, the relevant authorization objects, and whether the OData service and ICF node behind the tile are active. Clear the launchpad cache last, not first.
- Fiori launchpad catalogs groups and spacesCatalogs are the technical container that binds a tile to its target mapping and grants authorization through a PFCG role. Groups, and in the newer model spaces and pages, control what the user actually sees and how it is arranged on the home screen. A tile can exist in a catalog, fully authorized, and still be invisible because nobody put it on a group or a page.