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.
No comments:
Post a Comment