1. What happens when you set-up a new configuration?
Ans: When a new configuration in the SAP LT Replication Server is created, the database connection is automatically created along with a schema 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.
The mapping of mass transfer IDs and related schema are stored in the SLT control table DMC_MT_HEADER in the SAP LT Replication Server.
2. What are the jobs involved in replication process?
Ans: Following jobs are involved in replication process:
- Master Job (IUUC_MONITOR_<MT_ID>)
- Master Controlling Job (IUUC_REPLIC_CNTR_<MT_ID>)
- Data Load Job (DTL_MT_DATA_LOAD_<MT_ID>_<2digits>)
- Migration Object Definition Job (IUUC_DEF_MIG_OBJ_<2digits>)
- Access Plan Calculation Job (ACC_PLAN_CALC_<MT_ID>_<2digits>)
3. What is the purpose of master job (IUUC_MONITOR_<MT_ID>)?
Ans: Every 5 seconds, the monitoring job checks in the SAP HANA system whether there are new tasks and, if so, triggers the master control jobs. It also deletes the processed entries (tasks) from table RS_ORDER and writes statistics entries into table RS_STATUS (in the relevant schema in the SAP HANA system).
4. What is the purpose of master controller job (IUUC_REPLIC_CNTR_<MT_ID>)?
Ans: This job is scheduled on demand and is responsible for:
- Creating database triggers and logging table in the source system
- Creating synonyms
- Writing new entries in admin tables in SLT server when a new table is loaded/replicated
5. What is the purpose of Data Load Job (DTL_MT_DATA_LOAD_<MT_ID>_<2digits>)?
Ans: This job should always be active. If the job does not complete successfully, the master controller job restarts it.
This job is responsible for:
- Loading data (load)
- Replicating data (replication)
- Changing status flag for entries in control tables in the SAP LT Replication Server
6. What is the purpose of Migration Object Definition Job (IUUC_DEF_MIG_OBJ_<2digits>)?
Ans: This job defines the migration object of a specific table (that you choose to load/replicate), which is the fundamental object for LT replication. The migration object definition should normally be quite fast for all tables.
7. What is the purpose of Access Plan Calculation Job (ACC_PLAN_CALC_<MT_ID>_<2digits>)?
Ans: This job calculates the access plan of a specific table (that you choose to load/replicate), and the access plan is used for data load or replication. The access plan is also a fundamental object for the replication. For a normal sized table, access plan calculation should finish quite quickly (less than 1 minute) while large tables might take up to several hours to finish.
8. What is the relation between the number of data transfer jobs in the configuration settings and the available BGD work processes?
Ans: 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”.
9. 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?
Ans:
- 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)
10. What happens after the SLT replication is over?
Ans: 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
11. What are the different replication scenarios?
Ans: Different replication scenarios are:
Load, Replicate, Stop, Suspend and Resume.
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:
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).
12. What happens if the replication is suspended for a long period of time or system outage of SLT or HANA system?
Ans: The size of the logging tables increases.
13. How to avoid unnecessary logging information from being stored?
Ans: Pause the replication by stopping the schema-related jobs.
14. Will the table size in SAP HANA database and in the source system the same?
Ans: No.
As HANA database supports compression, the table size in SAP HANA may be decreased.
15. When to go for table partitioning?
Ans: 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).
16. Where do you define transformation rules?
Ans: By using “Advanced replication settings” (transaction IUUC_REPL_CONT, tab page IUUC ASS RULE MAP)
17. Are there any special considerations if the source system is non-SAP system?
Ans: The concept of trigger-based replication is actually meant for SAP source systems.
In case of non-SAP system, following points should be kept in mind:
- 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 are supported as non-SAP source systems.
18. Does SLT for SAP HANA support data compression like SAP HANA database?
Ans: Yes, this is automatically covered by the RFC connection used for data replication from the SAP source system.
Ans:
- The SAP HANA studio is an Eclipse-based development and administration tool for working with HANA.
- It enables technical users to manage the SAP HANA database, to create and manage user authorizations, to create new or modify existing models of data etc.
- It is a client tool, which can be used to access local or remote HANA system.
Ans:
Modeler:
Used for creating various types of views and analytical privileges.
SAP HANA Development:
Used for programming applications for creating development objects to access or update data models such as Server-side Java script, XSJS, XSODATA files.
Administration:
Used to monitor the system and change settings.
Debug:
Used to debug code such as SQLScript (.procedure files) or Server-side Java script (.xsjs files).
To open a perspective, go to Window → Open Perspective.
No comments:
Post a Comment