cancel
Showing results for 
Search instead for 
Did you mean: 

anyway to restart mergedog?

nicholas_chang
Active Contributor
0 Kudos

Hi All,

Our client is on rev70 and memory consumption for the system is high due to high delta store memory, for eg: DELTA_GB for SAP schema is 100GB whilst MAIN_GB is just 10GB  for column store.

Besides that, M_CS_TABLE show high memory size in delta as compare to memory size in main. Looking at Merge Statistic info, delta merge did run. I can see "START_TIME" is recent and up to date, with type "RECLAIM" and MEMORY_MERGE = "TRUE". However, did a check on runtime for each particular table, Memory consumption in delta storage is still high and not reduce at all. Merge method is system default.

Check the "merge" process in performance-> load, system resource was not utilized for merge process. Analyze index trace, couldn't find any error log.

mergedog parameter is set correctly. Did a comparison with other system.

Therefore, instead of delta merge each and every tables, is there anyway to ensure mergedog is running correctly? I assume perform a HDB restart will restart mergedog as well, correct me if i'm wrong.

All kind input is very much appreciated.

Thanks,
Nicholas Chang

Accepted Solutions (1)

Accepted Solutions (1)

lbreddemann
Active Contributor
0 Kudos

Hi Nicholas

you can easily double check on the mergedogmonitor process by displaying it in the Administration Console -> Performance -> Threads.

Make sure the filter settings include mergedogmonitor and that the <active> filter is disabled.

You'll see something like this then:

Apart from that, I believe the threshold function will simply not indicate a merge for your tables.

You may look into the mergedogmonitor trace (trace level INFO) to get a report on the evaluation.

- Lasr

nicholas_chang
Active Contributor
0 Kudos

Hi Lars,

Thx for the info. Below i can see the mergedog are available, however, it only active for 2-3s and non of the tables were merge for indexserver.

I've compare the delta merge process with another system, where most of the similiar tables under the sap schema in indexserver were merge.

I believe below statistic was abnormal where the last merge time for this system were a month ago, with high DELTA GB as compare to MAIN for CS:

M_CS_TABLE:

i) Look at the MEMORY_SIZE_IN_DELTA compare to MEMORY_SIZE_IN_MAIN:

ii) Look at the LAST_MERGE_TIME:

look at the merge statistic for eg: REPOSRC table, the start time is April. Little confuse here, what's the diff between START_TIME here with the LAST_MERGE_TIME in M_CS_TABLE??

fyi, there's no error indicated in merge statistic.

Now look at the runtime info for reposrc: Memory consumption for delta storage is high:

REPOSRC is just an example, and it happens to most tables in the schema.

I've manully perform the delta merge for few tables, and used database memory is reduce significantly, as well as the delta storage memory for those tables.

Hope to hear from you again,

Thanks,

Nicholas Chang

lbreddemann
Active Contributor
0 Kudos

Ok, what's missing here is that you compare the storage numbers with what's in your merge decision function.

Typically the function is setup in a way that is a little bit more complex than "if the delta log is large then merge".

- Lars

nicholas_chang
Active Contributor
0 Kudos

Hi Lars,

able to to figure out the culprit after investigate the trace with level "info" turned on.

auto merge and critical merge parameter was changed and not using default level:

once reset them back to default level, delta merge back to normal and significant drop on database memroy.

However, no one change the parameter above as client doesnt has access in hana studio. What we did was patching via SUM month ago, would suspect could the parameter changed by SUM? Coincidentally the merge process problem occur around the same period.

Try to google around, manage to find the note below:

1860493 - Out of memory during import migration to HANA

Besides, anyway we can trace who change to parameter?

Thanks for your kind input in advance.

Cheers,

Nicholas chang

lbreddemann
Active Contributor
0 Kudos

Well, I told you: it's the decision function

SUM is definitively not messing with these or any other parameters.

And no, there is no way to track back who changed the parameters.

Since I've seen customers running with similar manual setting, I would suspect that these come from some "best practice" document of sorts that is floating around in the consulting space.

However, the recommendation for these parameters always had been: use the default or better know well what you are doing.

Just set the parameters back and you should be fine.

And don't forget to turn off the trace again.

- Lars

nicholas_chang
Active Contributor
0 Kudos

Thanks Lars! Much appreciate!

0 Kudos

we had same issue in our enviornemnt . DSO activations were running for a very long time in our production and had so many high priority alert for delta storage being of huge size . It turned out to fix memory error during HANA migration we changed the parameter auto_merge_decision and critical_merge_decision as per SAP note 186049 3 . after putting values to default the activations were smooth . and also you dont have to restart your instance to change these parameter . they are dynamic . mergedog restart is needed (which happens once in 60 second interval default )

Answers (1)

Answers (1)

former_member182114
Active Contributor
0 Kudos

Hi Nicholas,

Take a look on System Information -> Merge Statistics.

The most recent merge operations will be visible.

Check for date/time if it's recent and try to find if your table is there and the result of operation (sometimes you find the merge operation ended in error).

Regards, Fernando Da Rós