21. How can unnecessary logging information from being stored be avoided?
Unnecessary logging information storage can be avoided by pausing the replication which is by stopping the schema-related jobs.
Unnecessary logging information storage can be avoided by pausing the replication which is by stopping the schema-related jobs.
22. Are the table size in SAP HANA database and in the source system the same?
No they are not same as HANA database supports compression.
23. When is table partitioning opted?
If the table size in HANA database exceeds 2 billion records, the table should be splitted by using portioning features by using “Advanced replication settings” (transaction IUUC_REPL_CONT, tab page IUUC_REPL_TABSTG).
If the table size in HANA database exceeds 2 billion records, the table should be splitted by using portioning features by using “Advanced replication settings” (transaction IUUC_REPL_CONT, tab page IUUC_REPL_TABSTG).
24. Where are transformation rules defined?
Transformation rules are defined by using “Advanced replication settings” (transaction IUUC_REPL_CONT, tab page IUUC ASS RULE MAP)
25. If the source system is non-SAP system, are there any special considerations?
The trigger-based replication concept is actually meant for SAP source systems. The main differences are as below :
a) There would be a database connection between non-SAP source and SLT system instead of RFC.
b) Source must have primary key
c) Tables DD02L, DD02T which contains metadata are just initially loaded but not replicated.
d) The read modules resides on SLT system.
e) Tables with database specific formats may need transformation rules just before they are replicated.
f) Only SAP supported databases (with respective DBSL for SAP Net Weaver 7.02) are supported as non-SAP source systems.
26. State the potential issues in the creation of a configuration?
The most potential issues in the configuration creation is the 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 ) and if the Logon credentials are not correct.
27. How is it ensured that data is consistent in source system and HANA system?
Since any changes in the source system that occurs is tracked in the dedicated logging tables, the replication status for each changed data record will be transparent.
An entry of logging table is deleted after an every 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 SLT for SAP HANA supports data compression like SAP HANA database and this is automatically covered by the RFC connection used for data replication from the SAP source.
29. What is Auto Documentation feature in HANA?
When the user creates Views in HANA Studio under “Contents”, he can automatically generate the documentation about the views. This generated document will have the details about all the view belongs to a package which he selected for Auto Documentation.
The user can invoke the Auto Documentation from three places.
- Right click Context menu of the Package or the Views
- On the top right corner of the opened view
- Quick Launch->Content->Auto Documentation
30. If tables of a schema are used to build modeling views then it’s necessary to grant SELECT privilege to user _SYS_REPO. Why?
If tables of a schema (say SCHEMA_ABC) are used to build modeling views, then following SQL statement must be executed before activating any such modeling views.
GRANT SELECT ON SCHEMA SCHEMA_ABC TO _SYS_REPO WITH GRANT OPTION
Think of _SYS_REPO as "the activation guy".
It takes your models and creates the necessary runtime objects from them.
Therefore user _SYS_REPO needs the allowance to select YOUR tables/views.
(If _SYS_REPO user cannot select on the tables specified in the from-clause of the view-definition, it cannot define that view)
If other users need to select this view (obviously this is always the case, otherwise the views would not make sense), then _SYS_REPO needs to have the additional allowance to grant the select further (WITH GRANT OPTION).
Therefor after having activated all your models that access data in your schemas, _SYS_REPO wants to give you (and probably other users) read access to the activated models.
GRANT SELECT ON SCHEMA SCHEMA_ABC TO _SYS_REPO WITH GRANT OPTION
Think of _SYS_REPO as "the activation guy".
It takes your models and creates the necessary runtime objects from them.
Therefore user _SYS_REPO needs the allowance to select YOUR tables/views.
(If _SYS_REPO user cannot select on the tables specified in the from-clause of the view-definition, it cannot define that view)
If other users need to select this view (obviously this is always the case, otherwise the views would not make sense), then _SYS_REPO needs to have the additional allowance to grant the select further (WITH GRANT OPTION).
Therefor after having activated all your models that access data in your schemas, _SYS_REPO wants to give you (and probably other users) read access to the activated models.
No comments:
Post a Comment