Parallel Replication taking time using SLT configuration

Parallel Replication taking time using SLT configuration
This question is Not Answered.
Saritha K
26-Nov-2013 11:04
Hi Experts,
My SLT version is 2011_1_731 sp 5. My configuration works fine for small tables but it
becomes slow when it comes to loading large transparent table like CE11000. I followed
steps mentioned in blog " How to improve the initial load" written by Tobias and started
replication with below parametersMy replication remains in initial load process with calculation showing 'S for more than 3hrs
and then it started showing status 'P' when 1LT/MWB_CALCSACP_001_Z_CE11000 started
running.
in table IUUC_PRECALC_OBJ my entries are conv object- CE11000
NUMREC 145000000
in table IUUC_PERF_OPTION my entries are tabname - CE11000
PARALLEL JOBS- 5
SEQNUM - 20
READING TYPE 5
and my SLT Server configuration has below count of jobs No of Data Transfer jobs - 4
Initial load jobs - 7
No of calculation jobs -2
If I do a table health check in its calculation phase ( status P), using tcode- LTRC-> Expert
FunctionsChecks for table CE11000 (mass transfer ID 001) started
Last action is R-Load tables and start replication, status is O-Obtained (Scheduled); "Is Last"
= Yes (from 26.11.2013 05:28:54)
Current action is R-Load tables and start replication; status is O-Obtained (Scheduled)
Log table /1CADMC/00000212 created in sender system, and has 0 records
The following triggers are defined for table CE11000:
- /1LT/00000212INS
Trigger CE11000; status is 2-Activated
Latency data for table CE11000 is not available
Migration object =Z_CE11000_001;Defined? = Yes, Generated? = Yes (X = Yes, blank = No)
No access plan found for table CE11000
Access plan set as 'Not Calculated' in table DMC_MT_TABLES for table CE11000
Checks for table CE11000 finished (mass transfer ID 001)
The troubleshooting activity has detected critical issues
Currently I can see number of records getting updated in the job log of
1LT/MWB_CALCSACP_001_Z_CE11000 but I cannot see any ACC_PLAN_CALC_001_0 jobs.
Please suggest your opinion on below points to accelerate initial load1. options that we can check for monitoring if something in replication is failing apart from
above steps
2. parameters that need to be added additionally incase required
3. any correction notes required to be installed for our mentioned configuration.
Regards,
Saritha
Helpful Answers by Saritha K, Guenter Weber, Saritha K, Guenter Weber, Guenter Weber
1908 Views

Average User Rating
(0 ratings)
Helpful AnswerRe: Parallel Replication taking time using SLT configuration
Saritha K 26-Nov-2013 13:52 (in response to Saritha K)

Hi All,
To add to my above question, the replication failed for job /
1LT/MWB_CALCSACP_001_Z_CE11000_ / 08463900 after running for about 4hrs(which means
my replication in initial load ran for status S-3hrs and status P- 4hrs) with below errorInternal session terminated with a runtime error DBIF_RTAB_SQL_ERROR
ST22 messages- short text
SQL error 1691 when accessing table "DMC_INDXCL".
Database error text
Error Text of the Database: "ORA-01691: unable to extend lob segment
SAPSR3.SYS_LOB0000327172C00006$$ by 128 in tablespace PSAPSR3"
Please suggest some steps on how to resolve it.
Regards,
Saritha
o
Alert Moderator
o
Helpful AnswerRe: Parallel Replication taking time using SLT
configuration
Like (0)
Guenter Weber 26-Nov-2013 14:42 (in response to Saritha K)

Hi Saritha,
two remarks:
1.
Once the status has switched from 'S' to 'P' that means that the
parallelization is defined. You can now start, as shown in the blog, additional access
plan calculation jobs. This will result in a considerably shorter time to finish this
activity.
2.
Concerning the shortdump, you need to keep in mind that in the
course of the access plan calculation activity, the data to be transferred to HANA are
first stored in the source system in an INDX-like table named DMC_INDXCL. You need
to make sure that enough space is available in the corresponding tablespace, which
here is PSAPSR3. We normally assume a compression factor of 1:10, so if you want
to select 300 GB of data for loading to HANA, you need to provide at least 30 GB,
possibly a bit more, of tablespace to make sure that the above problem will not
occur
Kind regards,
Guenter
Alert Moderator
Like (0)

configuration
Saritha K 26-Nov-2013 14:55 (in response to Guenter Weber)

Hi Guenter,
-Thanks for your reply, we have data of around 485 GB, and we have increased it by 60GB
but I have a query now- from this step, if I have to restart my failed replication, how should I
do it?
My /1LT/MWB_CALCSACP_001_Z_CE11000_ / 08463900 had read 86,000,000 records and as
per our estimate it should have reached 145, 000,000.
Is there a way to resume by setting any indicator in the expert options of tcode- mwbmon?
Regards,
Saritha
Alert Moderator
Re: Parallel Replication taking time using SLT
Like (0)
configuration
PITIRIM TAN 26-Nov-2013 15:41 (in response to Saritha K)

I do not know if there is restart capability after an error. We've been having short dumps in
our parallel processing. To start from the beginning we have successfully used the steps in
this document. We have not had to use the ABAP steps.
http://maben.homeip.net/static/computers/sap/HANA/starter/0410%20-%20Data
%20Provisioning%20-%20SLT%20for%20HANA%201.0%20-%20Repairing%20Replication
%20Errors%20with%20ABAP%20Program%20Automation.pdf
Alert Moderator
Like (0)
configuration
Saritha K 27-Nov-2013 06:27 (in response to PITIRIM TAN)

Hi Pitirim Tan,
Thank you for the pdf, I was able to retrigger the job /1LT/MWB_CALCSACP_001_Z_CE11000_
which had got cancelled and now I have a new problem.
My failed job started with access plan 2 which triggered plan 3, 4 in sequence. As per
Guenter's suggestion when I set the additional access plan setting, it triggered a new job for
plan 5 as well. Now the status is as below/1LT/MWB_CALCSACP_001_Z_CE11000_2 instances are running parallel.
Is there way to restart the job only for access_plan 1 which is missing now?
Another query that I have is, whether on acp jobs completion, will my load run successfully?
Regards,
Saritha
Alert Moderator
Like (0)
Re: Parallel Replication taking time using
SLT configuration

Hi Saritha,
unfortunately a job for access plan calculation that has run in the source system and got
cancelled needs to start again from scratch. But the parallelization should alleviate this
problem, as the job only processes a subset and not all the data of the respective table.
Kind regards,
Guenter
Alert Moderator
Like (0)
Re: Parallel Replication taking time
using SLT configuration

Hi Guenter,
Sorry I couldn't interpret your answer.
Do you mean to say - that the loading will start automatically after these 2 instances get
over and load tables into HANA with whatever rows in present in DMC_INDXCL table?
Within 2-3hrs I expect my access plans/1LT/MWB_CALCSACP_001_Z_CE11000 jobs to get
over.
If I go to tcode- mwbmon-steps -> calculate access plan - > execute function and give below
parameters- mass transfer id - 0001 tablename - CE11000 Number of jobs to be scheduled5 and also mark the RESTART option this time, alongwith setting of do not
recalculate precalculations and access plans that have been
calculated
what will be the impact- will it
restart with my missing access plan and ignore the remaining ones as it has been
calculated?
or
I also know to trigger the cancelled job again from SM37 by passing variants at runtime
or
should I ignore the access plan 1 data for now, as DMC_INDXL will have some 86, 000,000
rows that were stored before job got cancelled, so let it proceed with loading after above
jobs get
completed?
Please give some
overview on which option I should go for and why ..
Regards,
Saritha
Alert Moderator
Like (0)
Re: Parallel Replication taking
time using SLT configuration

Hi Saritha,
there is no need to directly start the jobs from SM37, but you can do it from MWBMON the
way you described. Just keep one thing in mind: If you mark the restart option while 2 jobs
are already running, and you want to start another 2 jobs, you need to specify 4 as the
number of jobs. The restart option means that the number of jobs you specify is the TOTAL
number of jobs that should run, so we calculate the difference between the number of
currently running jobs and the number of jobs that you specify, and schedule this number of
jobs. As soon as all access plans are calculated, the overall status of the table will switch to
calculated = 'X', and the initial load will start.
Kind regards,
Guenter
Alert Moderator
Like (0)
Re: Parallel Replication
taking time using SLT configuration

Hi Guenter,
Yesterday we tried out with the restart option, but it didn't work out due to some reason, the
calculation process remainined in 'P' status as a result , the load process never got triggered.
Finally we had to clean up the tables after replication error and have started a fresh start.
Hope this gets completed .
Currently I have set 2 additional calculation plans to run parallely.
Just one more query from my end, after these access plans get completed, would the load
jobs also run parallely or do i need to set it those jobs as well parallely after the load jobs 1st
instance starts running from mwbmon - steps - load data and any particular field that I need
to enter as such.
Regards,
Saritha.
Alert Moderator
Like (0)
Hi Saritha,
this is strange, in such a case this should rather be handled with a OSS message.
Concerning the parallelization of the initial load, that will work without any forther manual
activities. You only need to keep in mind that by default, we don't allow more than three jobs
running in parallel for a certain table. If you need more, the ideal case is that you have
defined the degree of parallelization in transaction iuuc_repl_content before starting the
replication of that table. Otherwise you can define it in transaction MWBMON.
Kind regards,
Guenter
o
Alert Moderator
o
Re: Parallel Replication taking time using SLT configuration
Like (0)

Hi Guenter,
This time the access plans were calculated without any interruption:) , and I have 4
loads running in parallel currently as in my LTR configuration I have "initial load jobs
count =4"
From iuuc_repl_content, how do I set this parallelization? frm mwbmon, I believe its the
same ways as I stated above right..
Regards,
Saritha
Alert Moderator
Like (0)

Hi Saritha,
when you have selected the configuration in iuuc_repl_content, you choose the tab
"IUUC_PERF_OPTION". There, you create an entry for the table in question, and maintain the
field "No of Parallel Jobs". But this needs to be done before you initiate the replication of the
respective table.
Kind regards,
Guenter
Alert Moderator
configuration
Saritha K 03-Dec-2013 09:40 (in response to Guenter Weber)

Hi Experts,
Like (0)
The steps documented for parallel replication of transparent table CE11000 worked out fine for
me. I tried the same steps for cluster table BSEG with reading type '4' this time and it started
out well with creation of 2 access calculation plans, 001 and 002. My job with access plan 002
got over after fetching around 24million records but there has been no update in job log 001 for
more than 19hrs.
Is there some additional setting that needs to be done when we try with replicating of large
cluster tables?
Why is it that replication of transparent table is faster than cluster table replication?
I also saw another approach where in we give selection criteria's based on primary key for
multiple access plans, but here we do not have an idea of how the data is widely distributed
across year, BELNR(Document Number) etc in order to judge the selection criteria.
Please suggest some technique which can be used for faster access of cluster tables into HANA.
Regards,
Saritha
Alert Moderator
Like (0)
configuration
Guenter Weber 03-Dec-2013 11:36 (in response to Saritha K)

Hi Saritha,
defining selection criteria based on the primary key is exactly what we do with reading type 4.
Concerning the problem with an access plan not being processed, it is necessary to analyze on DB
level why there is no progress. Among others, possible problems might be:
no space left in the tablespace to which table

DMC_INDXCL is assigned
in case of Oracle, in the course of time, it
becomes more and more difficult to return the data as they were at the time the selection began.
This might finally (but often only after some time with DB inactivity has elapsed) result in an ORA01555 "snapshot too old" shortdump
Cluster processing is always more time consuming because the data need to be declustered
(converted from the internal storage format to the format of the logical cluster table). Also note
that the number of records you specify, for the purpose of parallelization, in table
IUUC_PRECALC_OBJ is in this case the number of RFBLG records, not the number of BSEG records. I
would recommend a higher degree of parallelization (for example, 5 to 10 access plans, rather
than only 2) in order to achieve a shorter time for this access plan calculation processing step, and
(in case of Oracle) to minimize the risk of an ORA-01555 cancellation.
Kind regards,
Gnter
Alert Moderator
SLT configuration
Like (0)

Hi Guenter,
It wasnt due to tablespace issue for sure, but it seems my numrec for IUUC_PRECALC_OBJ that was not
correct, because I was not able to get the number of records thru both backgroun and foreground
processing.Will try again with different selection parameters. Thank you for the valuable inputs.
Regards,
Saritha
Alert Moderator
Like (0)
Saritha K 13-Dec-2013 13:45 (in response to Saritha K)

Hi Experts,
Need your help to replicate BSEG with reading type 4.
I was referring to SLT Reading Type 4 Replication PDF and in IUUC_REPL_CONTENT I have set partition by
GJAHR to 5 parts this time,
I have a count of BSEG table now which is around 176779953 records and I plan to split in 9 access plans
with slt configuration set to below set of jobsdata transfer jobs - 5
initial load jobs calculation jobs -5
Log tables etc got created after it was replicated but later on it got stuck meaning the table appeared 'in
process' state" table overview" tab but it just didn't appear in "Data transfer monitor" tab later on.
Can you please list out basic steps to carry out smooth replication of cluster table BSEG?
Note- HANA server version is upgraded to SP07
Regards,
Saritha
Alert Moderator
Like (0)
me using SLT configuration
ritha K 11-Feb-2014 06:10 (in response to Saritha K)

Experts, With the latest version of SLT(DMIS_2011_SP6), are there any changes in the steps for parallel
plication of transparent/cluster tables?
ould there be any additions required in table DMC_ACSPL_SELECT(a new table now available)?
anks,
ritha K
Alert Moderator
Like (0)
Helpful AnswerRe: Parallel
cation taking time using SLT configuration
ter Weber 11-Feb-2014 07:46 (in response to Saritha K)

itha,
d: By means of table DMC_ACSPL_SELECT you now can configure the parallelization of the replication of a
n table (regardless if transparent or cluster). For details, please refer to the online documentation of this
(SE11 - view table DMC_ACSPL_SELECT - choose "Goto - Documentation" from the menu). One important
needs to be added: In this table, you will define selection criteria for at least one primary key field of the
ponding table. You need to make sure that the secondary index of the logging table is defined in such a
hat this selection is well supported. Example: You want to replicate BKPF (or RFBLG / BSEG) in multiple
el threads, and your only criterion to define the subsets is the document number. Then the secondary index
respective logging table must not have the default field order:
PROCESSED
T
S
R
stead:
PROCESSED
R
eal case is that you predefine the parallelization before you even select the corresponding table for
ation. That means, you create a corresponding record in table IUUC_PERF_OPTION, where you would, in the
ple above, specify BELNR as the "parallel fieldname" (which means, the field for which we define
aries to subdivide the records in disjoint subsets). In this case, the field sequence mentioned above would
matically be used. Otherwise, you would need to redefine the secondary index of the logging table after it
y has been created, which is more difficult.
egards,
er
Alert Moderator
Like (0)
Joydeep Gupta 11-Feb-2014 13:42 (in response to Saritha K)

Saritha,
I would always suggest to do the Initilisation with SAP Data Services for large
tables.Defintely you need to have DS in your landscape for that.
1 Alert Moderator
2
3
Like (0)
Tobias Koebler 11-Feb-2014 14:00 (in response to Joydeep Gupta)

Hi Joy,
can you give some figures on the performance improvement DS vs. SLT for the initial load?
Our experience shows that most customer use SLT also for initial load.
Best,
Tobias
Alert Moderator
Like (0)
Joydeep Gupta 11-Feb-2014 14:37 (in response to Tobias Koebler)

Tobias -- Frankly speaking I have'nt tried that.
For large tables we have always initialised through DS & there is not a single issue till
date..Touchwood!!
Surely I would like to test those large tables through SLT in future.
Alert Moderator
Like (0)
configuration

Okey, yeah I would be pretty interessting. I think especially for really large BSEG (some SLT
customers have 50TB+) tables, etc. I would love to see DS figures to give further
recommendations.
Especially with the new SLT+DS integration this could lead to new use cases.
Best,
Tobias
Alert Moderator
Like (0)
configuration
Saritha K 13-Feb-2014 10:16 (in response to Tobias Koebler)
Hi Tobias,
I would like to know more about the SLT capability when we have a landscape consisting
ECC, BW to be replicated into BW on HANA.
I have some queries around this architecture.
Can we please discuss this offline if possible?
Thanks,
Saritha
Alert Moderator
Like (0)
SLT configuration
Tobias Koebler 13-Feb-2014 13:32 (in response to Saritha K)

Yes, just drop me a mail.
Best,
Tobias
Parallel Replication taking time using SLT configuration

Saritha K
26-Nov-2013 11:04
Hi Experts,
My SLT version is 2011_1_731 sp 5. My configuration works fine for small tables but it
becomes slow when it comes to loading large transparent table like CE11000. I followed
steps mentioned in blog " How to improve the initial load" written by Tobias and started
replication with below parametersMy replication remains in initial load process with calculation showing 'S for more than 3hrs
and then it started showing status 'P' when 1LT/MWB_CALCSACP_001_Z_CE11000 started
running.
in table IUUC_PRECALC_OBJ my entries are conv object- CE11000
NUMREC 145000000
in table IUUC_PERF_OPTION my entries are tabname - CE11000
PARALLEL JOBS- 5
SEQNUM - 20
READING TYPE 5
and my SLT Server configuration has below count of jobs No of Data Transfer jobs - 4
Initial load jobs - 7
No of calculation jobs -2
If I do a table health check in its calculation phase ( status P), using tcode- LTRC-> Expert
FunctionsChecks for table CE11000 (mass transfer ID 001) started
Last action is R-Load tables and start replication, status is O-Obtained (Scheduled); "Is Last"
= Yes (from 26.11.2013 05:28:54)
Current action is R-Load tables and start replication; status is O-Obtained (Scheduled)
Log table /1CADMC/00000212 created in sender system, and has 0 records
The following triggers are defined for table CE11000:
- /1LT/00000212INS
Trigger CE11000; status is 2-Activated
Latency data for table CE11000 is not available
Migration object =Z_CE11000_001;Defined? = Yes, Generated? = Yes (X = Yes, blank = No)
No access plan found for table CE11000
Access plan set as 'Not Calculated' in table DMC_MT_TABLES for table CE11000
Checks for table CE11000 finished (mass transfer ID 001)
The troubleshooting activity has detected critical issues
Currently I can see number of records getting updated in the job log of
1LT/MWB_CALCSACP_001_Z_CE11000 but I cannot see any ACC_PLAN_CALC_001_0 jobs.
Please suggest your opinion on below points to accelerate initial load1. options that we can check for monitoring if something in replication is failing apart from
above steps
2. parameters that need to be added additionally incase required
3. any correction notes required to be installed for our mentioned configuration.
Regards,
Saritha
Helpful Answers by Saritha K, Guenter Weber, Saritha K, Guenter Weber, Guenter Weber
1908 Views
Average User Rating

(0 ratings)
Saritha K 26-Nov-2013 13:52 (in response to Saritha K)

Hi All,
To add to my above question, the replication failed for job /
1LT/MWB_CALCSACP_001_Z_CE11000_ / 08463900 after running for about 4hrs(which means
my replication in initial load ran for status S-3hrs and status P- 4hrs) with below errorInternal session terminated with a runtime error DBIF_RTAB_SQL_ERROR
ST22 messages- short text
SQL error 1691 when accessing table "DMC_INDXCL".
Database error text

Error Text of the Database: "ORA-01691: unable to extend lob segment
SAPSR3.SYS_LOB0000327172C00006$$ by 128 in tablespace PSAPSR3"
Please suggest some steps on how to resolve it.
Regards,
Saritha
o
Alert Moderator
o
configuration
Like (0)

Hi Saritha,
two remarks:
1.
Once the status has switched from 'S' to 'P' that means that the
parallelization is defined. You can now start, as shown in the blog, additional access
plan calculation jobs. This will result in a considerably shorter time to finish this
activity.
2.
Concerning the shortdump, you need to keep in mind that in the
course of the access plan calculation activity, the data to be transferred to HANA are
first stored in the source system in an INDX-like table named DMC_INDXCL. You need
to make sure that enough space is available in the corresponding tablespace, which
here is PSAPSR3. We normally assume a compression factor of 1:10, so if you want
to select 300 GB of data for loading to HANA, you need to provide at least 30 GB,
possibly a bit more, of tablespace to make sure that the above problem will not
occur
Kind regards,
Guenter
Alert Moderator
Like (0)
configuration

Hi Guenter,
-Thanks for your reply, we have data of around 485 GB, and we have increased it by 60GB
but I have a query now- from this step, if I have to restart my failed replication, how should I
do it?
My /1LT/MWB_CALCSACP_001_Z_CE11000_ / 08463900 had read 86,000,000 records and as
per our estimate it should have reached 145, 000,000.
Is there a way to resume by setting any indicator in the expert options of tcode- mwbmon?
Regards,
Saritha
Alert Moderator
Like (0)
configuration
PITIRIM TAN 26-Nov-2013 15:41 (in response to Saritha K)

I do not know if there is restart capability after an error. We've been having short dumps in
our parallel processing. To start from the beginning we have successfully used the steps in
this document. We have not had to use the ABAP steps.
http://maben.homeip.net/static/computers/sap/HANA/starter/0410%20-%20Data
%20Provisioning%20-%20SLT%20for%20HANA%201.0%20-%20Repairing%20Replication
%20Errors%20with%20ABAP%20Program%20Automation.pdf
Alert Moderator
Like (0)
configuration
Saritha K 27-Nov-2013 06:27 (in response to PITIRIM TAN)

Hi Pitirim Tan,
Thank you for the pdf, I was able to retrigger the job /1LT/MWB_CALCSACP_001_Z_CE11000_
which had got cancelled and now I have a new problem.
My failed job started with access plan 2 which triggered plan 3, 4 in sequence. As per
Guenter's suggestion when I set the additional access plan setting, it triggered a new job for
plan 5 as well. Now the status is as below/1LT/MWB_CALCSACP_001_Z_CE11000_2 instances are running parallel.
Is there way to restart the job only for access_plan 1 which is missing now?
Another query that I have is, whether on acp jobs completion, will my load run successfully?
Regards,
Saritha
Alert Moderator
Like (0)
SLT configuration

Hi Saritha,
unfortunately a job for access plan calculation that has run in the source system and got
cancelled needs to start again from scratch. But the parallelization should alleviate this
problem, as the job only processes a subset and not all the data of the respective table.
Kind regards,
Guenter
Alert Moderator
Like (0)

Hi Guenter,
Sorry I couldn't interpret your answer.
Do you mean to say - that the loading will start automatically after these 2 instances get
over and load tables into HANA with whatever rows in present in DMC_INDXCL table?
Within 2-3hrs I expect my access plans/1LT/MWB_CALCSACP_001_Z_CE11000 jobs to get
over.
If I go to tcode- mwbmon-steps -> calculate access plan - > execute function and give below
parameters- mass transfer id - 0001 tablename - CE11000 Number of jobs to be scheduled5 and also mark the RESTART option this time, alongwith setting of do not
recalculate precalculations and access plans that have been
calculated
what will be the impact- will it
restart with my missing access plan and ignore the remaining ones as it has been
calculated?
or
I also know to trigger the cancelled job again from SM37 by passing variants at runtime
or
should I ignore the access plan 1 data for now, as DMC_INDXL will have some 86, 000,000
rows that were stored before job got cancelled, so let it proceed with loading after above
jobs get
completed?
Please give some
overview on which option I should go for and why ..
Regards,
Saritha
Alert Moderator
Like (0)
time using SLT configuration

Hi Saritha,
there is no need to directly start the jobs from SM37, but you can do it from MWBMON the
way you described. Just keep one thing in mind: If you mark the restart option while 2 jobs
are already running, and you want to start another 2 jobs, you need to specify 4 as the
number of jobs. The restart option means that the number of jobs you specify is the TOTAL
number of jobs that should run, so we calculate the difference between the number of
currently running jobs and the number of jobs that you specify, and schedule this number of
jobs. As soon as all access plans are calculated, the overall status of the table will switch to
calculated = 'X', and the initial load will start.
Kind regards,
Guenter
Alert Moderator
Like (0)
Re: Parallel Replication
taking time using SLT configuration

Hi Guenter,
Yesterday we tried out with the restart option, but it didn't work out due to some reason, the
calculation process remainined in 'P' status as a result , the load process never got triggered.
Finally we had to clean up the tables after replication error and have started a fresh start.
Hope this gets completed .
Currently I have set 2 additional calculation plans to run parallely.
Just one more query from my end, after these access plans get completed, would the load
jobs also run parallely or do i need to set it those jobs as well parallely after the load jobs 1st
instance starts running from mwbmon - steps - load data and any particular field that I need
to enter as such.
Regards,
Saritha.
Alert Moderator
Like (0)

Hi Saritha,
this is strange, in such a case this should rather be handled with a OSS message.
Concerning the parallelization of the initial load, that will work without any forther manual
activities. You only need to keep in mind that by default, we don't allow more than three jobs
running in parallel for a certain table. If you need more, the ideal case is that you have
defined the degree of parallelization in transaction iuuc_repl_content before starting the
replication of that table. Otherwise you can define it in transaction MWBMON.
Kind regards,
Guenter
o
Alert Moderator
o
Like (0)
Hi Guenter,
This time the access plans were calculated without any interruption:) , and I have 4
loads running in parallel currently as in my LTR configuration I have "initial load jobs
count =4"
From iuuc_repl_content, how do I set this parallelization? frm mwbmon, I believe its the
same ways as I stated above right..
Regards,
Saritha
Alert Moderator
Like (0)

Hi Saritha,
when you have selected the configuration in iuuc_repl_content, you choose the tab
"IUUC_PERF_OPTION". There, you create an entry for the table in question, and maintain the
field "No of Parallel Jobs". But this needs to be done before you initiate the replication of the
respective table.
Kind regards,
Guenter
Alert Moderator
Like (0)
configuration

Hi Experts,
The steps documented for parallel replication of transparent table CE11000 worked out fine for
me. I tried the same steps for cluster table BSEG with reading type '4' this time and it started
out well with creation of 2 access calculation plans, 001 and 002. My job with access plan 002
got over after fetching around 24million records but there has been no update in job log 001 for
more than 19hrs.
Is there some additional setting that needs to be done when we try with replicating of large
cluster tables?
Why is it that replication of transparent table is faster than cluster table replication?
I also saw another approach where in we give selection criteria's based on primary key for
multiple access plans, but here we do not have an idea of how the data is widely distributed
across year, BELNR(Document Number) etc in order to judge the selection criteria.
Please suggest some technique which can be used for faster access of cluster tables into HANA.
Regards,
Saritha
Alert Moderator
Like (0)
configuration
Guenter Weber 03-Dec-2013 11:36 (in response to Saritha K)

Hi Saritha,
defining selection criteria based on the primary key is exactly what we do with reading type 4.
Concerning the problem with an access plan not being processed, it is necessary to analyze on DB
level why there is no progress. Among others, possible problems might be:
no space left in the tablespace to which table

DMC_INDXCL is assigned
in case of Oracle, in the course of time, it
becomes more and more difficult to return the data as they were at the time the selection began.
This might finally (but often only after some time with DB inactivity has elapsed) result in an ORA01555 "snapshot too old" shortdump
Cluster processing is always more time consuming because the data need to be declustered
(converted from the internal storage format to the format of the logical cluster table). Also note
that the number of records you specify, for the purpose of parallelization, in table
IUUC_PRECALC_OBJ is in this case the number of RFBLG records, not the number of BSEG records. I
would recommend a higher degree of parallelization (for example, 5 to 10 access plans, rather
than only 2) in order to achieve a shorter time for this access plan calculation processing step, and
(in case of Oracle) to minimize the risk of an ORA-01555 cancellation.
Kind regards,
Gnter
Alert Moderator
Like (0)
SLT configuration

Hi Guenter,
It wasnt due to tablespace issue for sure, but it seems my numrec for IUUC_PRECALC_OBJ that was not
correct, because I was not able to get the number of records thru both backgroun and foreground
processing.Will try again with different selection parameters. Thank you for the valuable inputs.
Regards,
Saritha
Alert Moderator
Like (0)
Joydeep Gupta 11-Feb-2014 13:42 (in response to Saritha K)

Saritha,
I would always suggest to do the Initilisation with SAP Data Services for large
tables.Defintely you need to have DS in your landscape for that.
1 Alert Moderator
2
3
Like (0)

Hi Joy,
can you give some figures on the performance improvement DS vs. SLT for the initial load?
Our experience shows that most customer use SLT also for initial load.
Best,
Tobias
Alert Moderator
Like (0)
Joydeep Gupta 11-Feb-2014 14:37 (in response to Tobias Koebler)

Tobias -- Frankly speaking I have'nt tried that.
For large tables we have always initialised through DS & there is not a single issue till
date..Touchwood!!
Surely I would like to test those large tables through SLT in future.
Alert Moderator
Like (0)
configuration

Okey, yeah I would be pretty interessting. I think especially for really large BSEG (some SLT
customers have 50TB+) tables, etc. I would love to see DS figures to give further
recommendations.
Especially with the new SLT+DS integration this could lead to new use cases.
Best,
Tobias
Alert Moderator
Like (0)
configuration
Saritha K 13-Feb-2014 10:16 (in response to Tobias Koebler)

Hi Tobias,
I would like to know more about the SLT capability when we have a landscape consisting
ECC, BW to be replicated into BW on HANA.
I have some queries around this architecture.
Can we please discuss this offline if possible?
Thanks,
Saritha
Alert Moderator
Like (0)
SLT configuration
Tobias Koebler 13-Feb-2014 13:32 (in response to Saritha K)

Yes, just drop me a mail.
Best,
Tobias
Patrick Bachmann
18-Feb-2015 16:52
Hi folks,
I've been troubleshooting some major latency issues and have read a bunch of suggestions
in this forum which were quite old and wondering if there's any new approach/ideas on
troubleshooting latency problems. For my particular case I've been looking at
performance/load charts during the early morning slow down times and am not seeing any
high amount of delta merges or anything that indicates a problem on the HANA side. On SLT
I've increased amount of jobs processing and found some improvements however still seeing
delays where replication just stops for an hour or two at a time for certain tables. Talking to
some folks on my team they said DBA's suggested re-index tables on the SAP side could
improve things. I'm interested in understanding why that could help plus if there's any other
new ideas/suggestions to look for since some of the old posts were placed on SCN.
Thanks,
-Patrick
Helpful Answers by Lars Breddemann, Martin Frauendorfer
966 Views
Average User Rating

(0 ratings)
Re: Troubleshooting latency
Shakthi Raj Natarajan 18-Feb-2015 16:56 (in response to Patrick Bachmann)

Hi Patrick,
Can you please if back up running at a particular time and also check the availability of the
background jobs or delays in the background jobs.
Check both source system and replication server.
Thanks,
Shakthi Raj Natarajan.
o
Alert Moderator
o
Like (0)
Patrick Bachmann 18-Feb-2015 17:04 (in response to Shakthi Raj Natarajan)

Hi Shakthi,
Thanks for your suggestion, I am looking into these two questions now.
-Patrick
Alert Moderator
Like (0)
Patrick Bachmann 18-Feb-2015 19:45 (in response to Patrick Bachmann)

Ok I'm told backups are not happening during this time but I have to logon early morning to
view background jobs availability. I did talk to a dba who's theory around the index is that
the change tracking table (that also corresponds to the the synonym table in HANA) on the
SAP side initially is very large when the table is first replicated (lets say hundreds of millions
of records) and then subsequent replication after the first initial load there is just a small
amount of data in these tables yet the block size is showing very large. His theory is that
doing a re-org on the tracking table would rebuild the index and improve performance. I'm
wondering what others opinion is on this? I would think if this was the case then SAP would
make recommendations to re-org tables after every initialization of a large replication job. I
realize this may or not be the root of our problem but just investigating each and every
possibility.
-Patrick
Alert Moderator
Like (0)
Lars Breddemann 18-Feb-2015 21:05 (in response to Patrick Bachmann)

Hi Patrick,
index and table fragmentation definitively are effects that can occur on a platform like
Oracle.
However, these effects typically don't affect index based data access as much.
If the logging tables are access via full table scan every single time, this might be a reason
for slow access after a large growth of the tables.
This means, reading the logging entries from those tables might be slower than necessary.
That would be a constant slow down factor, not some effect that is sometimes there and
sometimes not.
Now, the question is: is the latency you try to analyze here affected by this at all? And are
the tables actually read by full table scans?
Common SAP on Oracle DBA activities would include checking for unnecessary large tables
and reorganizing those - and there are half-automatic tools available to do just that
(BRTOOLS). So, this possible problem can be addressed easily.
However, I highly recommend to not do anything before it is not clear what is causing the
problem. Just starting to reorganize and rebuild some data structures just because someone
heard something about that is going to do more harm than good.
You didn't yet state where your observed or perceived latency occurs.
Why don't you tell us more about what and where you saw the bad performance?
- Lars
Alert Moderator
Like (0)
Patrick Bachmann 18-Feb-2015 21:50 (in response to Lars Breddemann)

Hi Lars. I've just recently been handed SLT duties on top of my modelling ones so I've only
been beginning to dig into this in the past week or so after users complained of missing data
in their reports. I troubleshooted by looking at replication statistics in LTRC transaction and
first look at all tables for the day and sort by maximum latency. Then I take a look at each of
the worst tables by running the statistics by MINUTE for one table at a time and then I can
clearly see entries like this for MKPF;
02:00 AM 100 records latency 2.5 seconds
02:01 AM 105 records latency 3 seconds
I can clearly see records being updated every minute then suddenly there will be a gap of 1
or 2 hours with zero entries and it will jump like;
4:10 AM 5000 records latency 7680 seconds

4:13 etc...
These are not real numbers but just an example.
-Patrick
Alert Moderator
Like (0)
Helpful AnswerRe: Troubleshooting latency
Lars Breddemann 18-Feb-2015 22:33 (in response to Patrick Bachmann)

Alright,
I think it's quite clear that we can rule out now any fragmentation effects on the underlying
data structures.
It seems that there rather is some kind of waiting situation, e.g. caused by lock contention.
that slows down processing.
As I am not an SLT expert at all, I can only recommend a general approach.
So my next step would to check in both source and target system for long running
transactions and look for locks that might be involved with those.
It is important to know where the bottleneck occurs here. Since reading on Oracle (which I
assume is the source system here) typically is not blocked by record/table locks, I would
probably focus on the write-out end of the replication here - the SAP HANA server.
One thing that pops to my mind is that under some rare conditions the savepoint writing can
run into issues that then would lead to looping "critical phase"-executions. Those block
transactions and should be very short in general.
Martin's script collection (sap note #1969700) contains a script to check the savepoint
durations.
While you're at it, you should also run the minicheck script to get a general "health check".
In fact - start with the mini check and use work through the output first
- Lars
SLT Replication of BSIS table TIME_OUT

M. van Foeken
20-Mar-2013 11:33
I'm currently working on a SAP HANA project where SLT is used to replicate various SAP ECC
table to SAP HANA. I have managed to succesfully replicate various tables where the target
table structure is changed and filters are applied to filter the data which is inserted into SAP
HANA. Unfortunately I'm bumping into an issue with a large table called BSIS. The table
contains approx. 115 mln rows and generates a TIME_OUT. Other tables (largest 23. mln
rows) have been replicated succesfully.
Current behaviour is that during a period of 2400 seconds a dialog process is busy doing a
sequential read on the BSIS table. However after 40 min. it generates a TIME_OUT an start
all over again. Funny thing is that initially the table started to replicate with about 220.000
rows already replicated to SAP HANA. After that the process is looping in a 40 min. procedure
of reading, generating a TIME_OUT and starting all over again.
Does anybody have an idea what we could investigate to troubleshoot? Please let me know
which further information should be added to the discussion to help troubleshoot the issue.
SAP HANA is running op SPS05 rev. 51. DMIS component is 2011 SP3. All necessary
correction notes have been submitted (although the ones on ECC have been submitted after
the initial load for BSIS has started).
I have opened an OSS message but no response from SAP yet ;-(
Thanks for your reply!
With kind regards,
Martijn van Foeken
1644 Views
Tags: sap, hana, slt, time_out, bsis
Average User Rating
(0 ratings)
Re: SLT Replication of BSIS table TIME_OUT
Simon Jackson 21-Mar-2013 15:02 (in response to M. van Foeken)

Hi Martijn
One question that may help to point in the right direction, if I may ?
Is SLT running on a separate server or is your ECC system also your SLT system ?
It may be useful to share some information on your schema settings for the replication as
entered in LTR, such as how many data transfer jobs and initial load jobs do you have
configured ?
What status does table BSIS have in the Data Provisioning screen in HANA Studio ?
To troubleshoot, you may be able to get some direct feedback as to why the issues occur by
looking at either transaction MWBMON or IUUC_SYNC_MON ( both SLT transactions ).
Also, take a look at the system log, in both systems if SLT is separate to ECC.
If you know a dialog work process starts to process the replication, but then gives you a
TIME_OUT, have a look at the developer trace for the work process. The dump, visible in
ST22, that occurs when you have the TIME_OUT may also help.
You may need to delete the original load of BSIS in HANA and start again, given that
corrections have been applied to SLT after the initial load.
Is it possible the issue is in HANA ?
Take a look at the Administrator perspective in HANA Studio and check all alerts.
I've not seen a TIME_OUT in ECC for any of our current replication scenarios, but I hope this
feedback helps you to diagnose the issue.
regards
Simon.
o
Alert Moderator
o
Like (0)
M. van Foeken 21-Mar-2013 21:26 (in response to Simon Jackson)

Hi Simon,
First of all thanks for your reply! I the meantime we decided to not wait for the response
from SAP on the OSS message but continue with some other options.
After trying a few small tables which all replicated perfectly we started to load another 'big'
table with 58 mln. records, the BSAS table. So far this is running perfectly.
For the first time however we noticed that the BSIS table went into error.
To be complete let me answer your questions and provide additional information:
----------------------One question that may help to point in the right direction, if I may ?
Is SLT running on a separate server or is your ECC system also your SLT system ?
It is a separate system
It may be useful to share some information on your schema settings for the replication as
entered in LTR, such as how many data transfer jobs and initial load jobs do you have
configured ?
2 initial load job and 10 data jobs
What status does table BSIS have in the Data Provisioning screen in HANA Studio ?
On load for a long time but today it switched to load/error
To troubleshoot, you may be able to get some direct feedback as to why the issues occur by
looking at either
transaction MWBMON or IUUC_SYNC_MON ( both SLT transactions ).
Is there somewhere some explanation about these transactions? I knew them already but
can't find much information about them
Also, take a look at the system log, in both systems if SLT is separate to ECC.
No errors on the SLT system, only on the ECC system. And the only error there is explainable
(TIME_OUT) somehow the data load takes longer then 40 minutes. And that is on the
acceptance system the limit for a proces to take use of a dialog process. 40 minutes
however, is already an extremely big value for a timeout so the question is why the data
load does take so long.
If you know a dialog work process starts to process the replication, but then gives you a
TIME_OUT, have a look at the developer trace for the work process. The dump, visible in
ST22, that occurs when you have the TIME_OUT may also help.
You may need to delete the original load of BSIS in HANA and start again, given that
corrections have been applied to SLT after the initial load.
What do you mean by this? I can empty the BSIS table of course in Hana but that won't
cancel the data
load job itself. And as long as the job runs I cannot kill it to restart it.
Is it possible the issue is in HANA ?
Everything is possible ;-) but I doubt it, the hana system's CPU load is 0 and also the SLT
system does not seem to retrieve any data of this specific table. Other tables were
replicated without issues by the way but BSIS table is the biggest we tried so far. Problem
seems to be that the data load runs in a dialog work process instead of a BTC and that it
takes longer then 40 minutes
Take a look at the Administrator perspective in HANA Studio and check all alerts.
So far I haven't notices any issues in Hana itself
I've not seen a TIME_OUT in ECC for any of our current replication scenarios, but I hope this
feedback helps you to diagnose the issue.
What is the largest table that you replicated to hana?
-----------------------
Thanks for your reply!

With kind regards,
Martijn van Foeken
Alert Moderator
Like (0)
Simon Jackson 27-Mar-2013 16:41 (in response to M. van Foeken)

Hi Martijn
Thanks for spending time to reply.
Our largest tables, in a sandbox environment using an ECC system refreshed from a
production system, are over 800million records.
I've spoken to my functional expert as regards your scenario with BSIS.
He asked the question have tables BKPF and BSEG also been replicated to HANA ?
Following on from my earlier questions, probably the most important question to ask, I think,
is about the reading type you have used for BSIS in SLT and whether you have anything in
IUUC_PERF_OPTION ?
Also, do you have filtering enabled for your replication ?
If so, where is it enabled ? On the ECC system or on the SLT server ?
If the filtering is set in ECC, then this may be the cause of your TIME_OUT in the ECC system.
Sorry to answer questions with questions - we may come to a solution between us
Thanks
Simon.
Alert Moderator
Like (0)
N. van der Linden 28-Mar-2013 13:09 (in response to Simon Jackson)

Dear Simon,
Thanks for your reply, I'm a colleague of Martijn and working together on this issue so I will
try to answer your questions.
have tables BKPF and BSEG also been replicated to HANA ?
No we did not replicate those, but we also tried the BSIS table from a smaller sandbox
(which contains only 600.000 entries and there it synced fine (also without those two
tables).
whether you have anything in IUUC_PERF_OPTION?
No initially not, however, the table BSAS contains 58.000.000 (which is less then
115.000.000 ofcourse) and this one synced (also without this option) fine in a few hours. As I
understood the 'normal' replication method will already replicate only 10.000 records per
time and with the IUUC_PERF_OPTION you would be able to increase the performance of the
initial load by breaking the whole table in smaller sizes and running multiple replication jobs
together. In our case it is not an performance problem but it occupies an dialog process for
more then 40 minutes (which is our time out for dialog work processes) and then gives a
TIME_OUT shortdump (so it never sends records at all). I monitored the replication of the
BSAS table and there it only occupied a dialog work process on ECC for 20 seconds after
which it started a new process in another dialog work process. So that is a big difference and
looks like the BSAS table was indeed send in parts of 10.000 records and it seems that it
tries to send the whole BSIS table at once (otherwise I cannot explain why it occupies an
work process on ECC for more then 40 minutes).
do you have filtering enabled for your replication?
yes we use filtering on the SLT in transaction 'iuuc_repl_content'. Under "IUUC REPL TABSTG"
we adjusted the table structure to exclude some fields which we do not need. All fields part
of the key are included in the replication though. And under the tab "IUUC *** RUL MAP" we
added an line of code filter for the "beginning of record" event. The line of code we use is 'IF
<WA_R_BSAS>-BUDAT LE '20100930'. SKIP_RECORD. ENDIF.' but both filters are also used on
the BSAS table.
For the BSAS table this means that only 17.000.000 records of the 58.000.000 records are
replicated (without issues) and for the BSIS it means that it should only replicate 37.000.000
of the 115.000.000 records. I don't know if Martijn mentioned it before but the BSIS table did
replicate 200.000 records before the issues started.
We do have on important question, don't know if you have an answer for this?
Currently the BSIS table is still running an initial load. This will never finish since no data is
send from ECC to SLT (all jobs end in a TIME_OUT shortdump). We like to try to add the
'IUUC_PERF_OPTION' option however, in order to do this we need to stop the load. It is easy
to stop (or suspend) an existing replication from the hana studio but you don't have the stop
or suspend options for tables which are on the initial load. So how can we reset this table
replication so that it uses the new configuration?
Kind Regards,
Nico van der Linden
Alert Moderator
Like (0)
Kris Stono 28-Mar-2013 13:41 (in response to N. van der Linden)

Hi Nico,
You could try (at your own risk) via function module IUUC_REPL_STOP_REPLICATION direct in
the SLT system, what I am not sure about is whether the table has to be in the 'replication'
status in order for this to work. However, the safest way would be to open a message with
SAP as they can stop the jobs for you.
I assume you are trying to create some open/cleared items queries given that you are
loading the BSIS tables...perhaps a better way for HANA is to load BKPF and BSEG. You will
need to use a different reading type for BSEG.
Good luck
Kris
Alert Moderator
Like (0)
N. van der Linden 28-Mar-2013 14:27 (in response to Kris Stono)

Dear Kris,
thanks for your answer. It is good to know this function module, we do have an OSS message
(with priority high) but it takes ages before SAP replies on them but we will wait a little
longer and otherwise we can try this function module to see if the jobs stop.
We will have an look at the other tables but it was on request of the business that table BSIS
was replicated.
However, if anyone knows what the reason could be that the ECC dialog work process is
occuppied for more then 40 minutes then I would be very happy. I hope that it is solved
when we adjust IUUC_PERF_OPTION (as soon as our job is stopped), but I doubt it a bit since
we replicated other big tables without issues.
Thank you all for your replies so far.
Kind Regards,
Nico
Alert Moderator
Like (0)
Re: SLT Replication of BSIS table
TIME_OUT
Kris Stono 28-Mar-2013 15:04 (in response to N. van der Linden)

Hi Nico,
Can you check the reading type for BSIS...reading type 2 tries to read the whole table in one
portion...just a guess that could explain the TIME_OUT? Wlse wait for the SLT wizards to reply
:-)
Thanks
Kris
Alert Moderator
Like (0)
N. van der Linden 11-Apr-2013 08:22 (in response to Kris Stono)

Hi Kris (and others),
we are going to try to replicate this table again with a different reading type. But we did get
a reply from SAP in how to stop an running Initial Load.
You have to stop the master job in transaction LTR, then in the hana studio you execute the
SQL statement
insert into <schema>."RS_ORDER" values('<SID>','<hostname>','<tablename>',0,'C');
The values for <SID> and <hostname> are the ones that are displayed in the data
provisioning perspective in the HANA studio. The hostname is the name of the SAP instance
of the source system, usually something like <hostname>_<SID>_<system number>
depending on your DMIS version you might have to use the SQL statement "insert into
<schema>."RS_ORDER" values('<SID>','<hostname>','<tablename>',0,'C','','','');"
after you restart the master job the table replication will be stopped and you can restart the
initial load. The RS_ORDER table will be empty again after the restart of the master job.
Hopefully the replication problem will be solved as well now for us but I will let you know
later. I just wanted to share this part already since it is not very good documented yet.
Kind Regards,
Nico...
Alert Moderator
Like (0)
Re: SLT Replication of BSIS table
TIME_OUT
Jomy Joy 11-Mar-2014 20:55 (in response to N. van der Linden)

Hi Nico,
Were you able to solve this issue with BSIS ?
It would be great, if you can share this information with us.
Thanks & regards,
Jomy
Alert Moderator
Like (0)
Re: SLT Replication of BSIS
table TIME_OUT
N. van der Linden 11-Mar-2014 21:01 (in response to Jomy Joy)

Hi Jormy,
yes we fixed it eventually by using a different reading type for this table (4 if I remember
correctly).
Kind Regards,
Nico van der Linden
Error occured when openning db connection

This question has been Answered.
Keerthan Shetty
Jan 23, 2013 5:36 AM
Hi Experts,
We have installed an SAP Hana System(HANA 1.0 SPS5) with an SAP LT
Replication server(DMIS 2011 SP2-3) and SAP source system(DMIS 2011 SP1-3).
The system hosting the SAP LT Replication Server is an SAP system with SAP
NetWeaver 7.02 (Basis Support Package 11) ABAP stack using SAP Kernel 7.20
EXT(64BIT Unicode) and patch level is 400.
we have successfully connected SAP LT Replication server and SAP source system
through RFC.But whenever we create a new configuration schema for connecting
SAP Hana System and SAP LT Replication server: the dynpro dialog raises an
error:
Error occurred when opening db connection

Verification of Schema failed due to connection issues
The RFC destinations working fine.

Please help us on this.Thanks in advance.
FYR:You can download SAP Hana installation guide from the SAP Service
Marketplace at the Internet address:
https://websmp204.sap-ag.de/~sapidb/011000358700000604912011
Correct Answer by Keerthan Shetty on May 23, 2013 9:48 AM

Hi Norman,
Thank you for your response. But in my case the problem is solved after upgrading the
kernel from 720 ext level 400 to 721 level 40.
Thanx,
Keerthan
See the answer in context
Helpful Answer by Alex Liu
3085 Views
Products: sap_hana Tags: hana, database_connection, replication_server, dmis, db_co
nnection,schema_failed
Average User Rating
(1 rating)
Re: Error occured when openning db connection
Satyam Poddar Jan 23, 2013 5:56 AM (in response to Keerthan Shetty)
Hi Keerthan,
Have you tried to check the compatibilty of the various components that you have installed,
as mentioned in the SAP installation guide ?
Satyam
o
Alert Moderator
Like (1)
Keerthan Shetty Jan 23, 2013 6:18 AM (in response to Satyam Poddar)
Hi Satyam,
I have installed DMIS - Release (2011_1_700) - Level (3) to the system hosting Replication
Server and DMIS - Release (2011_1_730) - level (3) to the Source system which is a BW
system. The HANA version is HANA 1.0 SPS5. According to the document, they are
compatible with each other.
Alert Moderator
Like (0)
Helpful AnswerRe: Error occured when openning db connection
Alex Liu Jan 23, 2013 10:16 AM (in response to Keerthan Shetty)
i knew this problem. before you create a schema via Trascation Code "LTR". Please make
sure: 1) HANA Client is installed in SLT server. 2) Basis Kenerl is installed in SLT server.
Once you have done both condition, you can try to create HANA DB connection in SLT server
via follwing way. 1) RUN DBCO, and filled in connection information. 2) Test this connection
via SE38(Report Name: ADBC_TEST_CONNECTION) If all these condition are ok, you can do
your job in LTR webdynpro and start data replication work.
Alert Moderator
o
o
Like (1)
Keerthan Shetty Jan 24, 2013 8:36 AM (in response to Alex Liu)
Hi,
I installed HANA DBSL and HANA client as well and tried creating the configuration again but
it showed the same error.
I ran the report ADBC_TEST_CONNECTION and it showed the following error.
Loading DB library 'E:\usr\sap\HLT\DVEBMGS00\exe\dbhdbslib.dll' ...

*** ERROR => DlLoadLib()==DLENOACCESS LoadLibrary("E:\usr\sap\HLT\DVEBMGS00\exe\dbhdbslib.dll")
Error 193 = "E:\usr\sap\HLT\DVEBMGS00\exe\dbhdbslib.dll is not a valid Win32 application."
[dlnt.c
255]
{root-id=4487FCA5D1FB1ED299BECA4E635FA381}_{connid=00000000000000000000000000000000}_0
*** ERROR => Couldn't load library 'E:\usr\sap\HLT\DVEBMGS00\exe\dbhdbslib.dll'
[dbcon.c
5767]
please help.
Alert Moderator
Like (0)
Hello Brother..
You did all things are correct !!! But you forgot a most important thing...
If you look at error message. SAP Basis Kenerl Could not load "dbhdbslib.dll"... What this
error message told you?
Answer is :
1) You told me that you have install HANA Client and DBSL...
2) But System told you it could not load DBSL(hana lib..xxx)
You have to add "HANA Client Instllation Path" in your OS Environment

Variable(SLT based), reference your OS environment below.
AIX
HP-UX
Linux
LIBPATH
SHLIB_PATH
LD_LIBRARY_PATH
Solaris
LD_LIBRARY_PATH
Windows
PATH
If your SLT was intalled Windows platformm, just add "installation path of hana
client" into this "PATH", and then restart OS and SLT Server.
once you have done this step... i promised that you can go ahead... create a schema and do
SLT data replication work.....
Alert Moderator
Like (0)
Hi bro ,
we have followed the steps you advised above but still we are not able to create the new
configuration and getting the same error as specified above.please help.
Alert Moderator
Like (0)
Norman Pawelski May 19, 2013 10:56 AM (in response to Keerthan Shetty)
Hello Keerthan,
hopefully you already solved your problem. If not, I have possibly the solution as I had the
same problems like you.
What I did is to copy file libSQLDBCHDB.so to path /usr/sap/<SID>/DVEBMSG00/exe on the

source ERP System as this file was missing there. Further I set environment variable
LD_LIBRARY_PATH to /usr/sap/<SID>/hdbclient once again.
Hope this helps.
Have a nice weekend,

Norman.
Alert Moderator
Like (2)
Correct AnswerRe: Error occured when openning db connection
Keerthan Shetty May 23, 2013 9:48 AM (in response to Norman Pawelski)
Hi Norman,
Thank you for your response. But in my case the problem is solved after upgrading the
kernel from 720 ext level 400 to 721 level 40.
Thanx,
Keerthan
Alert Moderator
Naresh Pasumarthy May 24, 2013 5:26 AM (in response to Norman Pawelski)
Had the same issue and was able to resolve by copying the hdbclient tools in to exe
directory.
Like (1)
Thanks
Naresh
Alert Moderator
Like (2)
Eachann Chen Dec 23, 2014 4:25 AM (in response to Norman Pawelski)
Hello Norman,
My problem was also solved by your method. Many thanks!
In spite of the existing libSQLDBCHDB.so with permission 777 in

dir/usr/sap/<SID>/DVEBMGS00/exe/dbhdbslib.so, I copied it from /usr/sap/hdbclient/. Then
the exactly-the-same problem was solved
Best Regards,
Eachann
Alert Moderator
Like (0)
Saritha K 13-Dec-2013 13:45 (in response to Saritha K)

Hi Experts,
Need your help to replicate BSEG with reading type 4.
I was referring to SLT Reading Type 4 Replication PDF and in IUUC_REPL_CONTENT I have set partition by
GJAHR to 5 parts this time,
I have a count of BSEG table now which is around 176779953 records and I plan to split in 9 access plans
with slt configuration set to below set of jobsdata transfer jobs - 5
initial load jobs calculation jobs -5
Log tables etc got created after it was replicated but later on it got stuck meaning the table appeared 'in
process' state" table overview" tab but it just didn't appear in "Data transfer monitor" tab later on.
Can you please list out basic steps to carry out smooth replication of cluster table BSEG?
Note- HANA server version is upgraded to SP07
Regards,
Saritha
Alert Moderator
Like (0)
me using SLT configuration
ritha K 11-Feb-2014 06:10 (in response to Saritha K)Hi Experts,With the latest version of
T(DMIS_2011_SP6), are there any changes in the steps for parallel replication of transparent/cluster tables?
ould there be any additions required in table DMC_ACSPL_SELECT(a new table now available)?
anks,
ritha K
Alert Moderator
Like (0)
Helpful AnswerRe: Parallel
cation taking time using SLT configuration
ter Weber 11-Feb-2014 07:46 (in response to Saritha K)

itha,
d: By means of table DMC_ACSPL_SELECT you now can configure the parallelization of the replication of a
n table (regardless if transparent or cluster). For details, please refer to the online documentation of this
(SE11 - view table DMC_ACSPL_SELECT - choose "Goto - Documentation" from the menu). One important
needs to be added: In this table, you will define selection criteria for at least one primary key field of the
ponding table. You need to make sure that the secondary index of the logging table is defined in such a
hat this selection is well supported. Example: You want to replicate BKPF (or RFBLG / BSEG) in multiple
el threads, and your only criterion to define the subsets is the document number. Then the secondary index
respective logging table must not have the default field order:
PROCESSED
T
S
R
stead:
PROCESSED
R
eal case is that you predefine the parallelization before you even select the corresponding table for
ation. That means, you create a corresponding record in table IUUC_PERF_OPTION, where you would, in the
ple above, specify BELNR as the "parallel fieldname" (which means, the field for which we define
aries to subdivide the records in disjoint subsets). In this case, the field sequence mentioned above would
matically be used. Otherwise, you would need to redefine the secondary index of the logging table after it
y has been created, which is more difficult.
egards,
er
Error occured when openning db connection

This question has been Answered.
Keerthan Shetty
Jan 23, 2013 5:36 AM
Hi Experts,
We have installed an SAP Hana System(HANA 1.0 SPS5) with an SAP LT Replication
server(DMIS 2011 SP2-3) and SAP source system(DMIS 2011 SP1-3).
The system hosting the SAP LT Replication Server is an SAP system with SAP NetWeaver
7.02 (Basis Support Package 11) ABAP stack using SAP Kernel 7.20 EXT(64BIT Unicode)
and patch level is 400.
we have successfully connected SAP LT Replication server and SAP source system through
RFC.But whenever we create a new configuration schema for connecting SAP Hana System
and SAP LT Replication server: the dynpro dialog raises an error:
Error occurred when opening db connection

Verification of Schema failed due to connection issues
The RFC destinations working fine.

Please help us on this.Thanks in advance.
FYR:You can download SAP Hana installation guide from the SAP Service Marketplace at
the Internet address:
https://websmp204.sap-ag.de/~sapidb/011000358700000604912011
Correct Answer by Keerthan Shetty on May 23, 2013 9:48 AM

Hi Norman,
Thank you for your response. But in my case the problem is solved after upgrading the kernel from 720
ext level 400 to 721 level 40.
Thanx,
Keerthan
See the answer in context
Helpful Answer by Alex Liu
3085 Views
Products: sap_hana Tags: hana, database_connection, replication_server, dmis, db_connection,schema_fail
ed
Average User Rating

(1 rating)
Satyam Poddar Jan 23, 2013 5:56 AM (in response to Keerthan Shetty)
Hi Keerthan,
Have you tried to check the compatibilty of the various components that you have installed, as
mentioned in the SAP installation guide ?
Satyam
Alert Moderator
Keerthan Shetty Jan 23, 2013 6:18 AM (in response to Satyam Poddar)
Hi Satyam,
Like (1)
I have installed DMIS - Release (2011_1_700) - Level (3) to the system hosting Replication Server and
DMIS - Release (2011_1_730) - level (3) to the Source system which is a BW system. The HANA version
is HANA 1.0 SPS5. According to the document, they are compatible with each other.
Alert Moderator
Like (0)
Helpful AnswerRe: Error occured when openning db connection
i knew this problem. before you create a schema via Trascation Code "LTR". Please make sure: 1)
HANA Client is installed in SLT server. 2) Basis Kenerl is installed in SLT server. Once you have done
both condition, you can try to create HANA DB connection in SLT server via follwing way. 1) RUN DBCO,
and filled in connection information. 2) Test this connection via SE38(Report Name:
ADBC_TEST_CONNECTION) If all these condition are ok, you can do your job in LTR webdynpro and
start data replication work.
Alert Moderator
Like (1)
Hi,
I installed HANA DBSL and HANA client as well and tried creating the configuration again but it showed
the same error.
I ran the report ADBC_TEST_CONNECTION and it showed the following error.
Loading DB library 'E:\usr\sap\HLT\DVEBMGS00\exe\dbhdbslib.dll' ...

*** ERROR => DlLoadLib()==DLENOACCESS LoadLibrary("E:\usr\sap\HLT\DVEBMGS00\exe\dbhdbslib.dll")
Error 193 = "E:\usr\sap\HLT\DVEBMGS00\exe\dbhdbslib.dll is not a valid Win32 application." [dlnt.c

255]
{root-id=4487FCA5D1FB1ED299BECA4E635FA381}_{connid=00000000000000000000000000000000}_0
*** ERROR => Couldn't load library 'E:\usr\sap\HLT\DVEBMGS00\exe\dbhdbslib.dll'
[dbcon.c
5767]
please help.
Alert Moderator
Like (0)
Hello Brother..
You did all things are correct !!! But you forgot a most important
thing...
If you look at error message. SAP Basis Kenerl Could not load "dbhdbslib.dll"... What this error
message told you?
Answer is :
1) You told me that you have install HANA Client and DBSL...
2) But System told you it could not load DBSL(hana lib..xxx)
You have to add "HANA Client Instllation Path" in your OS

Environment Variable(SLT based), reference your OS environment
below.
AIX
HP-UX
LIBPATH
SHLIB_PATH
Linux
LD_LIBRARY_PATH
Solaris
LD_LIBRARY_PATH
Windows
PATH
If your SLT was intalled Windows platformm, just add "installation

path of hana client" into this "PATH", and then restart OS and SLT
Server.
once you have done this step... i promised that you can go ahead... create a schema and do SLT data
replication work.....
Alert Moderator
Like (0)
Hi bro ,
followed the steps you advised above but still we are not able to create the
new configuration and getting the same error as specified above.please help.
we have
Alert Moderator
Like (0)
Norman Pawelski May 19, 2013 10:56 AM (in response to Keerthan Shetty)
Hello Keerthan,
hopefully you already solved your problem. If not, I have possibly the solution as I had the same
problems like you.
What I did is to copy file libSQLDBCHDB.so to path /usr/sap/<SID>/DVEBMSG00/exe on the source ERP
System as this file was missing there. Further I set environment variable LD_LIBRARY_PATH to
/usr/sap/<SID>/hdbclient once again.
Hope this helps.
Have a nice weekend,

Norman.
Alert Moderator
Like (2)
Correct AnswerRe: Error occured when openning db connection
Keerthan Shetty May 23, 2013 9:48 AM (in response to Norman Pawelski)
Hi Norman,
Thank you for your response. But in my case the problem is solved after upgrading the kernel from 720
ext level 400 to 721 level 40.
Thanx,
Keerthan
Alert Moderator
Like (1)
Naresh Pasumarthy May 24, 2013 5:26 AM (in response to Norman Pawelski)
Had the same issue and was able to resolve by copying the hdbclient tools in to exe directory.
Thanks
Naresh
Alert Moderator
Like (2)
Eachann Chen Dec 23, 2014 4:25 AM (in response to Norman Pawelski)
Hello Norman,
My problem was also solved by your method. Many thanks!
In spite of the existing libSQLDBCHDB.so with permission 777 in

dir/usr/sap/<SID>/DVEBMGS00/exe/dbhdbslib.so, I copied it from /usr/sap/hdbclient/. Then the exactlythe-same problem was solved
Best Regards,
Eachann

Parallel Replication taking time using SLT configuration

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Parallel Replication taking time using SLT configuration

Uploaded by

Copyright:

Available Formats

Parallel Replication taking time using SLT configuration

This question is Not Answered.

Saritha K 26-Nov-2013 13:52 (in response to Saritha K)

Guenter Weber 26-Nov-2013 14:42 (in response to Saritha K)

Helpful AnswerRe: Parallel Replication taking time using SLT

Saritha K 26-Nov-2013 14:55 (in response to Guenter Weber)

Re: Parallel Replication taking time using SLT

PITIRIM TAN 26-Nov-2013 15:41 (in response to Saritha K)

Saritha K 27-Nov-2013 06:27 (in response to PITIRIM TAN)

Guenter Weber 27-Nov-2013 07:18 (in response to Saritha K)

using SLT configuration

Saritha K 27-Nov-2013 08:31 (in response to Guenter Weber)

time using SLT configuration

Guenter Weber 28-Nov-2013 07:32 (in response to Saritha K)

taking time using SLT configuration

Saritha K 28-Nov-2013 10:26 (in response to Guenter Weber)

Guenter Weber 28-Nov-2013 13:58 (in response to Saritha K)

Saritha K 29-Nov-2013 06:09 (in response to Guenter Weber)

Guenter Weber 29-Nov-2013 07:55 (in response to Saritha K)

Re: Parallel Replication taking time using SLT

Saritha K 03-Dec-2013 09:40 (in response to Guenter Weber)

Guenter Weber 03-Dec-2013 11:36 (in response to Saritha K)

no space left in the tablespace to which table

Saritha K 04-Dec-2013 11:02 (in response to Guenter Weber)

using SLT configuration

Saritha K 13-Dec-2013 13:45 (in response to Saritha K)

me using SLT configuration

ritha K 11-Feb-2014 06:10 (in response to Saritha K)

cation taking time using SLT configuration

ter Weber 11-Feb-2014 07:46 (in response to Saritha K)

Re: Parallel Replication taking time using SLT configuration

Joydeep Gupta 11-Feb-2014 13:42 (in response to Saritha K)

Re: Parallel Replication taking time using SLT configuration

Tobias Koebler 11-Feb-2014 14:00 (in response to Joydeep Gupta)

Joydeep Gupta 11-Feb-2014 14:37 (in response to Tobias Koebler)

Re: Parallel Replication taking time using SLT

Tobias Koebler 11-Feb-2014 14:59 (in response to Joydeep Gupta)

Saritha K 13-Feb-2014 10:16 (in response to Tobias Koebler)

Tobias Koebler 13-Feb-2014 13:32 (in response to Saritha K)