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
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)
Helpful AnswerRe: Parallel Replication taking time using SLT 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) Re: Parallel Replication taking time using SLT
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
Guenter Weber 27-Nov-2013 07:18 (in response to Saritha K) 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
Saritha K 27-Nov-2013 08:31 (in response to Guenter Weber) 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
Guenter Weber 28-Nov-2013 07:32 (in response to Saritha K) 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
Saritha K 28-Nov-2013 10:26 (in response to Guenter Weber) 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) Helpful AnswerRe: Parallel Replication taking time using SLT configuration
Guenter Weber 28-Nov-2013 13:58 (in response to Saritha K)
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
o
Like (0)
Saritha K 29-Nov-2013 06:09 (in response to Guenter Weber) 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) Re: Parallel Replication taking time using SLT configuration
Guenter Weber 29-Nov-2013 07:55 (in response to Saritha K) 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 Re: Parallel Replication taking time using SLT
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) Re: Parallel Replication taking time using SLT
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, Günter Alert Moderator
SLT configuration
Like (0) Re: Parallel Replication taking time using
Saritha K 04-Dec-2013 11:02 (in response to Guenter Weber) 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) Re: Parallel Replication taking time
using SLT configuration
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) Re: Parallel Replication taking
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
2
Re: Parallel Replication taking time using SLT configuration
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)
Re: Parallel Replication taking time using SLT configuration
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) Re: Parallel Replication taking time using SLT configuration
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
Re: Parallel Replication taking time using SLT
Like (0)
configuration
Tobias Koebler 11-Feb-2014 14:59 (in response to Joydeep Gupta) 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) Re: Parallel Replication taking time using SLT
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) Re: Parallel Replication taking time using
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 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
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) Helpful AnswerRe: Parallel Replication taking time using SLT 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) Re: Parallel Replication taking time using SLT
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
Guenter Weber 27-Nov-2013 07:18 (in response to Saritha K) 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
Saritha K 27-Nov-2013 08:31 (in response to Guenter Weber) 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
Guenter Weber 28-Nov-2013 07:32 (in response to Saritha K) 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
Saritha K 28-Nov-2013 10:26 (in response to Guenter Weber) 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) Helpful AnswerRe: Parallel Replication taking time using SLT configuration
Guenter Weber 28-Nov-2013 13:58 (in response to Saritha K) 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
o Re: Parallel Replication taking time using SLT configuration
Saritha K 29-Nov-2013 06:09 (in response to Guenter Weber)
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) Re: Parallel Replication taking time using SLT configuration
Guenter Weber 29-Nov-2013 07:55 (in response to Saritha K) 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 Re: Parallel Replication taking time using SLT
Like (0)
configuration
Saritha K 03-Dec-2013 09:40 (in response to Guenter Weber) 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) Re: Parallel Replication taking time using SLT
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, Günter Alert Moderator
Like (0) Re: Parallel Replication taking time using
SLT configuration
Saritha K 04-Dec-2013 11:02 (in response to Guenter Weber) 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
2
Re: Parallel Replication taking time using SLT configuration
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)
Re: Parallel Replication taking time using SLT configuration
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) Re: Parallel Replication taking time using SLT configuration
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
Re: Parallel Replication taking time using SLT
Like (0)
configuration
Tobias Koebler 11-Feb-2014 14:59 (in response to Joydeep Gupta) 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) Re: Parallel Replication taking time using SLT
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) Re: Parallel Replication taking time using
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
o
Like (0)
Re: Troubleshooting latency
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)
Re: Troubleshooting latency
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
Re: Troubleshooting latency
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
Re: Troubleshooting latency
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 02:02 AM 103 records latency 2.7 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:11 AM 100 records latency 2.5 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 This question is Not Answered.
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
o
Re: SLT Replication of BSIS table TIME_OUT
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)
Re: SLT Replication of BSIS table TIME_OUT
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.
Re: SLT Replication of BSIS table TIME_OUT
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
-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) Re: SLT Replication of BSIS table TIME_OUT
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) Re: SLT Replication of BSIS table TIME_OUT
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) Re: SLT Replication of BSIS table TIME_OUT
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 ."RS_ORDER" values('','','',0,'C'); The values for and 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 __ depending on your DMIS version you might have to use the SQL statement "insert into ."RS_ORDER" values('','','',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
o
Like (1)
Re: Error occured when openning db connection
o
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 o
Re: Error occured when openning db connection
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
Re: Error occured when openning db connection
Alex Liu Jan 24, 2013 8:53 AM (in response to Keerthan Shetty)
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
o
o
Like (0)
Re: Error occured when openning db connection
o
Keerthan Shetty Jan 25, 2013 11:08 AM (in response to Alex Liu) 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)
Re: Error occured when openning db connection
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//DVEBMSG00/exe on the source ERP System as this file was missing there. Further I set environment variable LD_LIBRARY_PATH to /usr/sap//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
Re: Error occured when openning db connection
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)
Re: Error occured when openning db connection
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//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) Re: Parallel Replication taking time
using SLT configuration
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) Re: Parallel Replication taking
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)
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 Alert Moderator
o
o
Re: Error occured when openning db connection
o
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
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)
Re: Error occured when openning db connection
o
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)
Re: Error occured when openning db connection
Alex Liu Jan 24, 2013 8:53 AM (in response to Keerthan Shetty) 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
o
o
Like (0)
Re: Error occured when openning db connection
o
Keerthan Shetty Jan 25, 2013 11:08 AM (in response to Alex Liu) 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)
Re: Error occured when openning db connection
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//DVEBMSG00/exe on the source ERP System as this file was missing there. Further I set environment variable LD_LIBRARY_PATH to /usr/sap//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)
Re: Error occured when openning db connection
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)
Re: Error occured when openning db connection
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//DVEBMGS00/exe/dbhdbslib.so, I copied it from /usr/sap/hdbclient/. Then the exactlythe-same problem was solved
Best Regards, Eachann
