50 top sap hana interview questions Email ThisBlogThis!Share to TwitterShare to Facebook

1.What are the different types of replication techniques ?

1.   ETL based replication using BODS2.   Trigger based replication using SLT3.   Extractor based data acquisition using DXC

2.What is SLT ?

    SLT stands for SAP Landscape Transformation which is a trigger based replication. SLT replication server is the replication technology to pass data from source system to the target system. The source can be either SAP or non-SAP. Target system is SAP HANA system which contains HANA database.

3.Is it possible to load and replicate data from one source system to multiple target database schemas of HANA system ?

    Yes. It is possible for up to 4.

4.Is it possible to specify the type of data load and replication ?

    Yes either in real time, or scheduled by time or by interval.

5. What is Configuration in SLT ?

    The information to create the connection between the source system, SLT system, and the SAP HANA system is specified within the SLT system as a Configuration. You can define a new configuration in Configuration & Monitoring Dashboard (transaction LTR).

6. Is there any pre-requisite before creating the configuration and

replication ?

    For the SAP source systems DMIS add-on is installed in SLT replication server. User for RFC connection has the role IUUC_REPL_REMOTE assigned but not DDIC.    For non-SAP source systems DMIS add-on is not required and grant a database user sufficient authorization for data replication.

7.What is Configuration and Monitoring Dashboard ?

    It is an application that runs on SLT replication server to specify configuration information (such as source system, target system, and relevant connections) so that data can be replicated. It can also use it to monitor the replication status (transaction LTR).

    Status Yellow: It may occur due to triggers which are not yet created successfully.

    Status Red: It may occur if master job is aborted (manually in transaction SM37).

  8.What is advanced replication settings ?

    A transaction that runs on SLT replication server to specify advanced replication settings like

    Modifying target table structures,     Specifying performance optimization settings     Define transformation rules

  9.What is Latency ?

    It is the length of time to replicate data (a table entry) from the source system to the target system.

  10.What is logging table ?

    A table in the source system that records any changes to a table that is being replicated. This ensures that SLT replication server can replicate these changes to the target system.

  11.What are Transformation rules ?

    A rule specified in the Advanced Replication settings transaction for source tables such that data is transformed during the replication process. Example you can specify rule to

    Convert fields     Fill empty fields     Skip records

  12.What happens when you set-up a new configuration ?

    The database connection is automatically created along with GUID and Mass transfer id (MT_ID).

    A schema GUID ensures that configurations with the same schema name can be created.

    The Mass transfer ID is used in the naming of SLT jobs and the system can uniquely identify a schema.

  13.What factors influence the change/increase the number of jobs ?

   Number of configurations managed by the SLT replication server

    Number of tables to be loaded/replicated for each configuration     Expected speed of initial load     Expected replication latency time.  As a rule of thumb, one BDG

job should be used for each 10 tables in replication to achieve acceptable latency times.

  14.When to change the number of Data Transfer jobs ?

    If the speed of the initial load/replication latency time is not satisfactory

    If SLT replication server has more resources than initially available, we can increase the number of data transfer and/or initial load jobs

    After the completion of the initial load, we may want to reduce the number of initial load jobs

 15.What are the jobs involved in replication process ?

    1. Master Job (IUUC_MONITOR_<MT_ID>)    2. Master Controlling Job (IUUC_REPLIC_CNTR_<MT_ID>)    3. Data Load Job (DTL_MT_DATA_LOAD_<MT_ID>_<2digits>)    4.Migration Object Definition Job (IUUC_DEF_MIG_OBJ_<2digits>)    5.Access Plan Calculation Job (ACC_PLAN_CALC_<MT_ID>_<2digits>)

  16.What is the relation between the number of data transfer jobs in the configuration settings and the available BGD work processes ?

    Each job occupies 1 BGD work processes in SLT replication server. For each configuration, the parameter Data Transfer Jobs restricts the maximum number of data load job for each mass transfer ID (MT_ID).

    A mass transfer ID requires at least 4 background jobs to be available:

    One master job     One master controller job     At least one data load job     One additional job either for migration/access plan

calculation/to change configuration settings in “Configuration and Monitoring Dashboard”.

 17.If you set the parameter “data transfer jobs” to 04 in a configuration “SCHEMA1”, a mass transfer ID 001 is assigned. Then what jobs should be in the system ?

   1 Master job (IUUC_MONITOR_SCHEMA1)     1 Master Controller job (IUUC_REPL_CNTR_001_0001)     At most 4 parallel jobs for MT_ID 001

(DTL_MT_DATA_LOAD_001_ 01/~02/~03/~04)     Performance:  If lots of tables are selected for load / replication

at the same time, it may happen that there are not enough background jobs available to start the load procedure for all tables immediately. In this case you can increase the number of initial load jobs, otherwise tables will be handled sequentially.

    For tables with large volume of data, you can use the transaction “Advanced Replication Settings (IUUC_REPL_CONT)” to further optimize the load and replication procedure for dedicated tables.

 18.What happens after the SLT replication is over ?

    The SLT replication server creates 1 user, 4 roles, 2 stored procedures and 8 tables.    1 User    1 Privilege    4 Roles    <REPLICATION SCHEMA>_DATA_PROV    <REPLICATION_SCHEMA>_POWER_USER    <REPLICATION_SCHEMA>_USER_ADMIN    <REPLICATION_SCHEMA>_SELECT    2 Stored procedures    RS_GRANT_ACCESS, RS_REVOKE_ACCESS    8 Tables    DD02L, DD02T, RS_LOG_FILES, RS_MESSAGES, RS_ORDER, RS_ORDER_EXT, RS_SCHEMA_MAP, RS_STATUS

 19.What are the different replication scenarios ?

    Load, Replicate, Stop, Suspend and Resume.

    Before you select any application table, the initial load of the tables DD02L, DD02T & DD08L must be completed as they contain the metadata information.

    Load: Starts an initial load of replication data from the source system. The procedure is a one-time event. After it is completed, further changes to the source system database will not be replicated.

    For the initial load procedure, neither database triggers nor logging tables are created in the source system. Default settings use reading type 3 (DB_SETGET) with up to 3 background jobs in parallel to load tables in parallel or subsequently into the HANA system.

    Replicate: Combines an initial load procedure and the subsequent replication procedure (real time or scheduled).

    Before the initial load procedure will start, database trigger and related logging table are created for each table in the source system as well as in SLT replication server.

    Stop Replication: Stops any current load or replication process of a table.

    The stop function will remove the database trigger and related logging tables completely. Only use this function if you do want to continue a selected table otherwise you must initially load the table again to ensure data consistency.

    Suspend: Pauses a table from a running replication. The database trigger will not be deleted from the source system. The recording of changes will continue and related information is stored in the related logging tables in the source system.

    If you suspend tables for a long time the size of logging tables may increase and adjust the table space if required.

    Resume: Restarts the application for a suspended table. The previous suspended replication will be resumed (no new initial load required).

 20.What happens if the replication is suspended for a long period of time or system outage of SLT or HANA system ?

    The size of the logging tables increases.

  21.How to avoid unnecessary logging information from being stored ?

    Pause the replication by stopping the schema-related jobs.

  22.Will the table size in SAP HANA database and in the source system the same ?

    No as HANA database supports compression.

  23.When to go for table partitioning ?

    If the table size in HANA database exceeds 2 billion records, split the table by using portioning features by using “Advanced replication settings” (transaction IUUC_REPL_CONT, tab page IUUC_REPL_TABSTG).

   24.Where do you define transformation rules ?

    By using “Advanced replication settings” (transaction IUUC_REPL_CONT, tab page IUUC ASS RULE MAP)

   25.Are there any special considerations if the source system is non-SAP system ?

    The concept of trigger-based replication is actually meant for SAP source systems. The main differences are:

    There will be a database connection between non-SAP source and SLT system instead of RFC.

    Source must have primary key     Tables DD02L, DD02T which contains metadata are just initially

loaded but not replicated.     The read modules reside on SLT system.     Tables with database specific formats may need transformation

rules before they are replicated.     Only SAP supported databases (with respective DBSL for SAP

Net Weaver 7.02) are supported as non-SAP source systems.

   26.What are the potential issues in the creation of configuration ?

    Missing add-on DMIS_2010 in source system     Missing the proper role of SAP_IUUC_REPL_REMOTE for RFC

user ( SAP_IUUC_USER for SLT system )     Logon credentials are not correct

   27.How can you ensure that data is consistent in source system and HANA system ?

    Since any changes in the source system is tracked in dedicated logging tables, the replication status for each changed data record is transparent. A entry of logging table is deleted after a successful commit statement from HANA database and this procedure ensures the data consistency between source system and HANA system.

  28.Does SLT for SAP HANA support data compression like SAP HANA database ?Yes, this is automatically covered by the RFC connection used for data

replication from the SAP source system.

  29. What are the product names?

    The short answer is: it's a mystery. SAP has changed them around a lot and now they call it SAP  HANA Appliance, SAP HANA Database and SAP HANA Studio. Applications built on HANA will be marked "powered by SAP HANA". Probably they will change it all again.

  30. What is SAP HANA Appliance 1.0?

    SAP HANA 1.0 is an analytics appliance that consists of certified hardware, an In Memory DataBase (IMDB) an Analytics Engine and some tooling for getting data in and out of HANA. You build the logic and structures yourself, and use a tool e.g. SAP BusinessObjects, to visualise or analyse data.

  31. What are the limitations of HANA 1.0?

    Quite a few so far - it can only replicate certain data, from certain databases, in certain formats, using the Sybase Replication Server. Batch loading is done using SAP BusinessObjects Data Services 4.0 and is optimised only for SAP BusinessObjects BI 4.0 reporting.

    32. What is SAP HANA 1.5, 1.2 or 1.0 SP03? 

    These are all the same thing, and 1.0 SP03 is touted to be the final name for what should go into RampUp (beta) in Q4 2011. This will allow any SAP NetWeaver BW 7.3 Data Warehouse to be migrated into a HANA appliance. HANA 1.0 SP03 specifically also accelerates BW calculations and planning, which means you get even more performance gains.

    33. What's the difference between HANA and IMDB?

    HANA is the name for the current BI appliance (HANA 1.0) and the BW Data Warehouse appliance (HANA 1.0 SP03). Both of these use the SAP IMDB Database Technology (SAP HANA Database) as their underlying RDBMS. Expect SAP to start to differentiate this more clearly as they start to position the technology for use cases other than Analytics.

    34. If I can run Net Weaver BW on IMDB/HANA, why can't I run the Business Suite/ERP 6.0?

    Simply because it's not mature enough yet to support business critical applications. From a technology perspective, it is already possible to run the Business Suite on IMDB and SAP has trialled

moving some large databases into IMDB already.

    35. What is HANA great at?

    The best thing that HANA brings to the table is the ability to aggregate large data volumes in near real-time - and to have the data updated in near real-time. SAP's demos show hundreds of billions of records of data being aggregated in a matter of seconds. SAP has built a set of Analytics Apps on top of HANA and this are set to be great point use cases to get customers up and running quickly.

    36. What is HANA bad at?

    There are some current issues around HANA when delivering ad-hoc analytics, especially when using the SAP Business Objects Webi tool. Essentially the problem is that you can ask computationally very difficult questions with Webi, which can cause very long response times with HANA. SAP will need to build optimization for both Webi and HANA to reduce the computational complexity of these questions, but they're not there yet.

    What's more, it's worth noting that HANA 1.0 is not a Data Warehouse and it is more of a Data Mart - that is, suited to point applications where there is a clear use case.

    37. What does HANA cost?

    SAP hasn't entirely confirmed HANA licensing costs but the hardware is somewhere around $1-200k per TB. Add to this licensing cost which are still being made on a per-customer basis.

    38. Why is HANA so fast?

    Regular RDBMS technologies put the information on spinning plates of iron (hard disks) from which the information is retrieved. HANA stores information in electronic memory, which is some 50x faster (depending on how you calculate). HANA stores a copy on magnetic disk, in case of power failure or the like. In addition, most SAP systems have the database on one system and a calculation engine on another, and they pass information between them. With HANA, this all happens within the same machine.

    39. Does HANA/IMDB replace Oracle?

    It's the elephant in the room, but once the Business Suite runs on IMDB, Oracle won't be needed any more by SAP customers who purchase HANA. This doesn't affect anything in the short term because those people buying HANA today will still need an Oracle ERP system.

    40. What is this about 10:1 compression with HANA compared to Oracle?

    A typical uncompressed Oracle or Microsoft SQL Server database, when put into HANA, will be 10x smaller than before and this is due to the way that HANA stores information in a compressed format. Note that most databases are now compressed and these numbers may not fit your scenario, and to add to this you need 2x the RAM as your database, plus room for growth. HANA sizing is still a dark art.

    41. You mean I have to buy a HANA only 2.5x smaller than my big Oracle RDBMS? What about archiving and data ageing?

    Yes, in some instances you may have to buy a HANA appliance that is only 2.5x smaller than it would be under Oracle. And data ageing isn't part of the 1.0 release, but SAP is certainly working on it pretty hard. Let's hope they release something faster than you need to buy a bigger HANA appliance!

    42. What's the wider market opportunity for IMDB?

    This is the interesting thing - no one knows yet, and few analysts seem to have cottoned on that the wider market opportunity might be huge. Think not just SAP applications but any third party that requires ultra-high speed. Think not just an appliance but a development platform. Time will tell. 

    2. SAP HANA database hardware 

    43. What hardware is supported right now? 

    Talk to your hardware vendor - all of the major vendors e.g. HP, IBM, Dell, have HANA offerings now. Technically HANA will run on any Intel x64 based system from your laptop through to the big 40-core, 2TB RAM servers. It is however only supported on a small number of big rack-mount servers like the Dell R910 and HP DL980. 

    44. Why doesn't HANA run on blades? 

    It's unclear but probably because the blades don't yet offer the same performance. HANA is optimized for the Intel X7560 CPU and will run fastest on this. And for instance, the Dell M910 blade can only run 2x X7650 CPUs and 512 GB RAM in this configuration, which probably explains the limitations. What's certain is that HANA will eventually run on blades - it's born to run on blade technology! 

    45. Does SAP make their own IMDB/HANA hardware? 

    Yes, but only in the labs so far. There are no public plans to compete against IBM/HP/Dell in this space, but it may make sense for SAP to enter the appliance market, especially in the context of Data Centres and even more so in the context of the SAP Business by Design cloud offering, which will run on IMDB. 

    46. How big does HANA scale? 

    Theoretically at least - very well. The biggest single-server HANA hardware will run most mid-size workloads - 2TB of in-memory storage is equivalent to 5-20TB of Oracle storage. The way that HANA works means that it is possible to chain multiple systems together - meaning that scalability has thus-far been determined by the size of customers' wallets. Do note that whilst SAP talk up "Big Data" quite a lot, HANA currently only scales to the small-end of Big Data, which refers to the kind of huge datasets that Face Book or Google have to store - not Terabytes, but rather Peta bytes. 

    47. What storage subsystem does HANA use? 

    This varies from vendor to vendor but it is shared network attached storage (NAS). Both regular magnetic disks and SSD storage can be used for the backup of the database (HANA runs in memory remember, so disk storage is just for backup, and later, for data ageing). Note that you require 2x storage that you have RAM, which is 2x the database size - i.e. storage size = 4x database size. In most cases there is additional ultra-high speed SSD storage for log files. 

    3. Technical FAQ 

    48. What source databases does HANA support in real-time? 

    If you use Sybase Replication Server (SRS) for near real-time data then you need to watch out for licensing still (SAP have license deals pending). If you run DB2 then you're fine but with Oracle and Microsoft SQL Server there are some license challenges if you buy your license through SAP, because you may have a limited license that does not allow extraction. Talk to SAP for further information on this. 

    48. What source databases does HANA support for batch loads? 

    If you use SAP Business Objects Data Services 4.0 for bulk loads then pretty much anything. BO-DS is a very flexible Extract, Transform & Load tool that supports many databases - check out the specs for more details. 

    49. What additional limitations does Sybase Replication Server

present? 

    SRS has additional restrictions which are worth bearing on mind. It can only replicate Unicode data and does not support IBM DB2 compressed tables.