SAP Basis Interview Questions

"Basis is the technical team behind SAP. We install and patch the systems, keep them running and fast, manage transports, users and background jobs, take and test backups, and do refreshes and upgrades. The functional and ABAP teams build the business side on top of what we run. A standard landscape has three systems: development, quality and production. Developers and consultants make changes in development, where they're recorded in transport requests. We move those transports to quality for testing, and only after sign-off do they go to production. That way nobody changes production directly, every change has an owner and an audit trail, and all three systems stay in step. Some companies add a sandbox for experiments or a pre-production system that mirrors production for final tests."

"When a user logs on through a logon group, the message server sends the GUI to the application server in that group with the best response time. On that server the dispatcher receives each request, puts it in a queue and hands it to a free work process. The work process runs the ABAP program, reads and writes the database through its own connection, and sends the screen back. After the step it rolls the user context out, so the same process can serve someone else a moment later. Around that, the gateway handles RFC calls from other systems and the ICM handles HTTP traffic, for Fiori or web services. The message server and the enqueue server, which holds the lock table, usually sit in the ABAP central services instance. That's a single point of failure, so in high availability setups we add an enqueue replication server and a cluster."

"Dialog work processes handle what users do on screen, and they also run incoming RFC requests. Background processes run scheduled jobs, so heavy reports don't block users. Update processes do the actual database changes after a user saves: V1, shown as UPD, handles the critical, time-sensitive changes, and V2, shown as UP2, handles lower-priority ones like statistics updates. The enqueue process manages the lock table, though in most modern setups that job belongs to the enqueue server in the central services instance instead. Spool processes format output and send it to printers. Every instance needs at least two dialog processes. When I size an instance I look at the workload: how many concurrent users, how many jobs run at once, and how busy updates get at peak times like month-end."

"Parameters are read from profile files in the profile directory. The default profile applies to every instance, the instance profile applies to one instance and overrides the default, and anything not set falls back to the kernel's built-in value. To make a lasting change I use RZ10: pick the profile, change it in extended maintenance, save and activate, and it's written to the file. Most parameters are static, so they only take effect after the instance restarts. RZ11 is for checking a parameter's current value, its documentation and whether it's dynamic. If it is, I can change it there and it applies at once, but that change lives only in memory. So if I use RZ11 in an emergency, I always make the same change in RZ10 too, or the next restart quietly undoes it."

"First I choose the domain controller. It holds the master TMS configuration, so it should be a system with good availability, often production. I run STMS there to create the domain, which sets up the TMSADM user and RFC destinations. Then I run STMS on quality and development, point them at the controller so they ask to join, and approve them on the controller. I make sure the transport directory is shared, or set up transport groups if it isn't. Then I define routes. A consolidation route goes from development to quality for the transport layer, usually both the standard SAP layer and the customer Z layer, so changes released in development land in quality's import queue. A delivery route goes from quality to production, so whatever is imported in quality also queues for production. Finally I distribute and activate the configuration, and test it by releasing a small transport and importing it all the way through."

"Return code 0 means everything imported cleanly. 4 means warnings, often fine, like an object that was already deleted. 8 means some objects failed, commonly a syntax error when programs were generated, or a missing dependency. 12 or higher means tp or R3trans was cancelled or hit a serious problem, like a missing file or a database issue. For an 8, I open the transport logs in STMS and look at which step failed, usually the generation or activation step, and read the object and the error. Very often it's a program that uses something from another transport that hasn't reached quality yet. Then I go to the developer with the exact object and message, and we either import the missing transport first or they fix it in development and release a new one. For a 12, I look at the tp log in the transport directory and check the data and cofiles files are really there."

"I'd pause before importing, because a transport carries the full version of an object, not just the lines that changed. If the developer built the fix on top of the untested change, importing the urgent transport brings that untested code into production too. And if the older transport goes to production later, it would overwrite the fix with an older version. So I compare the object lists and version history with the developer. If the fix is truly independent, we can go ahead. If not, there are two clean options: the developer rebuilds the fix on top of the production version, or testers check both transports together today and we import them in the right order. Either way I record it as an emergency change with approval, and make sure the older transport isn't imported later out of order."

"There are three kinds. A local copy with SCCL copies one client into another in the same system. A remote copy with SCC9 pulls a client from another system over RFC, which is handy but sensitive to network drops on big clients. A client export with SCC8 writes transport files, you import them in the target, and then run SCC7 for the post-import work. The profile decides what comes along. SAP_USER copies only users and roles, SAP_CUST copies customizing, SAP_UCUS does customizing plus users, and SAP_ALL copies all client-specific data including business data. Client copy never moves repository objects like programs, and cross-client customizing only comes along with an export profile that includes it, so the source and target should be on the same release and support package level. I run big copies in the background with parallel processes and check SCC3 for the log."

"SCC4 holds the settings for each client. The client role says what it's for, like customizing, test or production. Then there's how client-specific changes are handled: in the development customizing client they're allowed with automatic recording, so every change lands in a transport. In production they're set to no changes allowed. Next is cross-client changes, meaning repository objects and cross-client customizing: open in development, locked in quality and production. I also set protection so a production client can't be overwritten by a client copy. On top of that, SE06 has the system-wide change option, which should be not modifiable in quality and production. So production is locked at two levels, and opening it becomes a deliberate, logged act, not an accident."

"A dialog user is a real person: they log on through the GUI, must change their password on the rules we set, and multiple logons are checked. A system user can't log on in dialog; I use it for background processing and for RFC between systems inside the landscape, and its password isn't forced to change. A communication user is also non-interactive and is meant for RFC calls coming from external systems. A service user can log on in dialog but is shared and anonymous, like a public web service, so I give it very limited authorizations. A reference user can't log on at all; you assign it to other users so they inherit its authorizations, which helps when many users need the same extra rights. The main rule I follow is never to run an interface on a dialog user with broad rights, because if its password leaks, someone can log on with it."

"A single role holds the transactions in its menu and the authorization objects with their values, and generating it creates the profile that actually grants access. A composite role just groups single roles, so a job like accounts payable clerk can be one assignment made of several building blocks. It has no authorizations of its own. Derived roles solve a scaling problem. Say we have one role for purchasing, but buyers in each plant should only see their plant. I build a parent role, then create a derived role per plant. Each child inherits the menu and all authorization values from the parent and only changes the organisational levels, like plant or company code. When I change the parent, I push the change down to all children. After any change the profile must be generated, and user comparison run, or users won't get the new access. In many companies a separate security team owns this, but Basis often supports it."

"First I ask the user to reproduce the error and run SU53 straight away, or I display it for their user myself. It shows the last authorization check that failed: the object, like the one for a transaction start or a company code, and the values that were checked. Sometimes SU53 isn't enough, because it only shows the last failure and some checks happen quietly in the background. Then I switch on an authorization trace for that user with STAUTHTRACE or ST01, have them repeat the step, and read every check with its result. Once I know the exact object and value, I find the role that should cover this task, get approval from the role owner, and add the smallest change. I never fix it by copying roles from a colleague who can do it, because that usually brings a lot of extra access."

"I wouldn't say no straight away, and I wouldn't just open it either. First I'd ask what exactly needs to change and why it can't wait. Often the quickest safe route is a normal transport, fast-tracked: make the change in development, quick test in quality, and import within the hour. Some settings are also designed to be changed in production without opening the client, like opening posting periods, so it may not need anything from me. If it really must be changed directly, I'd follow the emergency change process: written approval, open the client and system change option for the shortest time, with the security audit log recording what's done, then close it again and confirm it's closed. And I'd make sure the same change is made in development and moved forward, or the next transport could overwrite it and the systems would drift apart."

"In SM36 I give the job a name and class, then add steps. A step is usually an ABAP program with a variant, but it can be an external command or program. Then the start condition: immediately, at a date and time, periodic, after another job finishes, or when an event is raised, which is useful when an outside system should trigger the job. In SM37 the status tells me where it is. Scheduled means it has no start condition yet, so it won't run. Released means it's waiting for its start time. Ready means the time came but no background process is free, so a long time in ready points to too few background processes. Active is running, finished is done, and cancelled means it failed. For a cancelled job I open the job log, and if it mentions a short dump I go to ST22 with the time and user."

"When a user saves a document, the dialog step usually doesn't write the business tables itself. It writes an update request into the update tables and gives the user a message, often with the document number. An update work process then posts the real changes, V1 for the critical part and V2 for things like statistics. If that update fails, SM13 shows it with an error status, and the painful part is that the user thinks their document is saved. So I treat terminated updates seriously. I look at the error info and the related dump in ST22 to find the cause, like a database error or a program bug. Once the cause is fixed, I can repeat the update if it's safe. If not, I give the functional team the list of users and documents, so they can check and re-enter them. I don't delete them without that agreement."

"SM50 lists the work processes on the instance I'm logged on to, and SM66 shows active processes across all instances, which is where I start in a multi-server system. For each process I look at type, status and time. If all dialog processes are running and the times keep climbing, something is holding them. The reason column helps: on hold with RFC means it's waiting on another system, and PRIV means it's using private memory and stuck to one user. The action and table columns show whether it's doing a sequential read on a big table or waiting on a lock. Then I look at the user and program, and call the person or the team that owns it before cancelling anything, because killing a process in the middle of a posting can leave a mess. If many processes wait on the database, I move to the database side next."

"In ST22 I filter by date and user, then open the dump. The runtime error name at the top is the key, then what happened, the error analysis, the source code extract showing where it stopped, and the user, transaction and program. A few I see often: TSV_TNEW_PAGE_ALLOC_FAILED means an internal table ran out of memory, usually a report selecting far too much data, though sometimes memory settings. TIME_OUT means a dialog step ran past the dialog time limit, so the user should run it in the background or the program needs tuning. DBIF_RSQL_SQL_ERROR means the database returned an error, so I check the database side, like space or locks. SYNTAX_ERROR or CALL_FUNCTION_NOT_FOUND right after an import usually means a transport is missing. I also search SAP notes with the error name and program, since many dumps are known bugs with a fix."

"First I compare against a normal period, not a single number, and check the time profile to see if it's all day or only peak hours. Then I split response time into its parts. If wait time has grown, requests are queuing in the dispatcher, so work processes are too few or tied up by something else. If database time dominates, I look at the top transactions by database time and trace the expensive SQL, or look for missing statistics or a new index need. If load and generation time is high, programs are being reloaded, often because the program buffer is too small or after a large import. If processing time is well above CPU time, the process is waiting on something outside, like RFC calls or locks. Then I use the transaction profile to see if one or two transactions or a new custom report explain most of it, because a system-wide average often hides one bad program."

"A user context in a dialog process starts in a small first slice of the roll area. Then it takes extended memory, which is shared and can be mapped to whichever process serves the user next. That's why dialog processes switch between users so easily. If the user hits their extended memory quota, or extended memory runs out, it uses the rest of the roll area and then falls back to heap, which is private to that process. At that point the process goes into PRIV mode: it stays attached to that one user and can't serve anyone else. A few of those are fine, but if many users run memory-hungry reports, dialog processes go PRIV one after another and everyone else waits. In the classic model, background processes take heap first because they never switch users, though newer kernels handle this differently, so I check the actual parameters. When I see PRIV in SM50, I check extended memory use and the reports behind it."

"In my last role, users complained every morning that sales order entry was slow, and everyone assumed the application servers needed more memory. Before agreeing, I checked ST03N for the morning hours and saw that response time for that transaction was mostly database time, not wait time or CPU. So more memory wouldn't have helped. I traced a few order saves and found one select on a custom table that read the whole table each time, because a recent change had dropped a field from the where clause. The table had grown a lot, so it only showed up now. I sent the developer the trace with the statement and the program, and they fixed the query in a day. Order entry went back to normal speed, and we avoided buying hardware we didn't need. Since then I always start by breaking down response time before accepting any theory."

"HANA works in memory, but it's fully durable. When a transaction commits, its redo log entries are written to the log volume on disk first, so the commit is safe even though the data pages are only in memory. Every few minutes a savepoint writes all changed pages to the data volume, giving a consistent image on disk. After a power loss, HANA restarts, loads from the last savepoint and replays the redo log written since then, so no committed data is lost. On the service side, the index server is the main one: it holds the column and row stores and runs SQL. The name server keeps track of the topology, which matters in a scale-out system. Current HANA versions always run as a system database that manages the tenants, and each tenant has its own index server. As Basis, I watch memory use per service, disk use of data and log volumes, and savepoint and log backup health."

"For production I keep the log mode at normal with automatic log backups on. Every filled log segment is backed up and then freed, and that chain of log backups is what lets me recover to any moment. I schedule full data backups, say weekly, with differential or incremental ones in between. Differential saves everything changed since the last full backup, incremental since the last data backup of any kind. I back up the system database as well as every tenant, and send backups to a separate storage or a backup tool through backint, never only to the same disks. Then I watch the backup catalog and alerts every day, because if log backups stop working, the log volume fills up and the database stops. And I restore to a test system on a schedule, because the only proof a backup works is a successful restore."

"With system replication, a second HANA system gets a full copy once, then receives the primary's redo log continuously, so it can take over quickly. The mode decides when the primary confirms a commit. In SYNC, the primary waits until the secondary has written the log to disk. In SYNCMEM, it waits until the secondary has received it in memory, which is a bit faster but at risk if both sites fail at once. In ASYNC, the primary doesn't wait, so it suits a distant disaster recovery site where the delay would hurt performance, at the price of possibly losing the last few transactions. For a takeover I make sure the primary is really down, run the takeover on the secondary with hdbnsutil, and move clients over with a virtual IP, DNS or the cluster software. Afterwards I re-register the old primary as the new secondary, so we never have two primaries writing."

"I start by choosing the target kernel patch, checking the notes and the product availability matrix for my release, OS and database. I download both the database-independent and the database-dependent archives, and check they match the platform. I always do development first, then quality, then production. On the day, I stop the SAP system and the start service, take a copy of the current exe directory so I can roll back in minutes, and extract the new archives into it with SAPCAR. On Unix I then run saproot.sh as root, so programs that need special permissions still work. I start the service and the system, check that all instances came up, confirm the new patch level in the system status or with disp+work, and look at the developer traces and system log for errors. If something breaks, I restore the saved exe folder and restart."

"SNOTE is for a single note: it downloads the correction instructions and applies them, including any prerequisite notes, though some notes also need manual steps. It's the smallest fix. SPAM imports ABAP support packages for components in a queue, and SAINT installs add-ons and can bring support packages with them. For anything bigger, like a release upgrade, an enhancement package or a large support package stack, I use the Software Update Manager, working from a stack file calculated in Maintenance Planner. SUM builds a shadow system and does much of the work while the system is still up, so the real downtime is shorter. Whenever SAP objects we modified are touched, we have to adjust. SPDD handles dictionary objects during the update, which matters because a wrong decision there can lose table data. SPAU handles programs and other objects afterwards, often resetting to standard when SAP's own fix replaced ours."

"Before the copy I save everything that makes quality what it is: users and roles with a client export, RFC destinations, partner profiles, certificates from STRUST, printers, the TMS setup and the list of transports in quality that aren't in production yet. I also agree the downtime and warn the teams. Then I restore a recent production backup into the quality database and run the system copy tool so it takes quality's name. The first thing after that is safety: I start the system with no background processes and suspend all released jobs with BTCTRNS1, and block outbound interfaces, so the copy doesn't send real payments, orders or emails. Then BDLS changes the logical system names from production to quality, SE06 post-copy steps, reconfiguring STMS, bringing back users, RFCs and certificates, installing the licence, and re-importing the pending transports. Where the data is personal, I apply the agreed masking. Finally the functional teams test and I hand over."

"Basis owns the technical path. First the prerequisites: the system must be Unicode and an ABAP-only stack, and Maintenance Planner has to accept our add-ons and business functions, or it blocks the conversion. I do HANA sizing, and run the readiness check and the simplification item checks, which flag what must be fixed before converting, like the Business Partner setup that the functional teams handle. Custom code is checked by the ABAP team. Then Maintenance Planner gives us the stack file, and I run SUM. If we're not on HANA yet, SUM with the database migration option does the upgrade and the move to HANA in one run. We never go straight to production. We run mock conversions on copies of production, time every phase, tune it, and write a detailed runbook. After the technical run come the finance data migration steps, which the functional team owns, plus Fiori setup and our usual post-steps."

"At my last company we applied a support package stack to production on a weekend with an eight-hour window. We had tested it in quality, which is a lot smaller. In production, one conversion phase ran far longer because a large table had grown much more than in quality. About halfway through the window I could see from the logs that at that rate we'd miss the deadline. I called the change manager and the finance lead, explained the numbers, and agreed a decision point: if it wasn't done by a set hour, we'd restore and try again another weekend. It finished just before that point, and we opened the system a bit late with their agreement. Afterwards I changed our approach: before any big change we now rehearse on a full-size copy of production and time each phase, and the runbook has a written go or no-go time for rollback."

"Early on, I did a quality refresh from production and followed the post-steps, but I missed one outbound RFC destination on my list. When jobs were released, a test process in quality sent a batch of order confirmations to a real partner system. A colleague on the interface team noticed within the hour. I stopped the job, locked the destination, and told my lead and the interface team straight away, so they could contact the partner and ask them to ignore the messages. Nothing was processed on their side, but it was embarrassing and could have been worse. Afterwards I turned our refresh checklist into a script that lists every outbound destination and partner profile and blocks them before the system starts, and a second person now signs off the checklist before jobs are released. I'd rather take ten extra minutes than repeat that."

"First I tell the finance lead I'm on it and when they'll hear from me next. If I can't log on, I check from the operating system, using sapcontrol or dpmon to see the work process table. Usually all dialog processes are busy, and the question is with what. If they're all running the same heavy report, I find who started it and agree to cancel those runs and move them to the background. If they're waiting on a lock or the database, I check the database side: a full log volume, a blocking session or a long transaction. If they're waiting on an RFC, I look at the other system. I also check the system log and the update queue. Once I know the cause, I free the blocker with the owner's agreement, not blindly. After month-end I write a root cause and fix it for good, like running that report as a job with limits."