cancel
Showing results for 
Search instead for 
Did you mean: 

Delete data in server quickly

Former Member
0 Kudos

hi,

we are going to change structure of syncBOs,and reinstall users' tablet , so we are going to delete data in server.

we know transactions called merep_purge and MEREP_RDB_T01_RESET,

but these transactions are very slow and we must not stop the server a long time.

do you know anoter way to clean the server quickly?

thanks

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Victor,

if you change structure of SyncBO then you need to generate BO again and so you are asked to delete actual Replica DB. Before able to activate BO again in MEREP_PD you are asked to replicate data first. This is the normal procedure. You can use MEREP_EX_REPLIC instead of running replication in MEREP_PD, but beside that the steps are necessary.

MEREP_PUGE cleans the logging table and removes unused data, but it is not necessary to run in case of changing BOs. MEREP_RDB_T01_RESET is the same function that is caeed by MEREP_SBUILDER while creating the BO again.

But restructure of BOs should be done and tested first on DEV system with a small dataset - why do you have the long replication time in that case?

Regards,

Oliver

Former Member
0 Kudos

hi Oliver!!

these are our index and tables, you can see they are very big

 Object   Type KBytes   Blocks

 MEREP_504   TABLE 64.925.696 8.115.712

 MEREP_604   TABLE 14.864.384 1.858.048

 MEREP_10700 TABLE 13.167.616 1.645.952

 MEREP_10700~LSK  INDEX 10.210.304 1.276.288

 MEREP_10700~0  INDEX 8.626.176 1.078.272

 MEREP_504~0   INDEX 8.357.888 1.044.736

 MEREP_10700~ITM  INDEX 7.971.840 996.480

 MEREP_10700~SBO INDEX 7.371.776 921.472

thanks

Former Member
0 Kudos

Hi,

well, ok, but this is only indirectly related to the change of a SyncBO structure. What type of BO are you using? T01 and T51 for example are stored in MEREP_207 - so any change of the BO is directly related to this table.

S01 is related to MEREP_10400 or 10700 - I am not exactly sure. but there it is the number of devices that blows up the table.

Have in mind: for each device you have a complete copy of the dataset on the middlewae spreaded over a few tables. So whatever information is on the device available you can see on these tables. Means on the other hand, that the more devices you have the bigger these tables are. This changes with MI7.1- but earlier versions are unfortunately designed like that. So the two questions are: what is the type of BO and how many devices do you have?

This shows a new issue as well: for testing you create devices, sync with them, delete them and create new ones. The old devices leaves its dataset in the tables as long as it was not deleted from the devicelist in NWA and you did run an MEREP_PURGE job afterwards.

Usually it is enough to run the PURGE job once a week and do not leave deleted devices to long in the DB.

Regards,

Oliver

Former Member
0 Kudos

hi Oliver,

there are 11 syncBOs T01 and 1 syncBO U01, and there are 380 devices

thanks

Former Member
0 Kudos

HiVictor,

in that case the size of the tables is clearly due to the devices. I am not sure if the design apers are freely available from SAP. These could show how a syncBO is syved in different tables. From my knowledge it is:

Replication of a SyncBO of Type T01 generates a copy of the data from backend in table MEREP_207. Each device has its own complete object store then as well in .... hopefully 10700. But anyway: the fact is: if you have one dataset on 380 devices, it is saved 380 times in 10700... or in the relevant table, whatever the exact name is, I have to search in the old papers. 504 is device related as well.

The problem is: these tables will grow more and more, the more devices you have. And if you throw a physical deviceinto the bin, the data still remains in the device tables 10700 and 504 - until you remote the device as well in NWA and then run MEREP_PURGE.

So the problem is not the restructuring of your data but the number of devices you have I think.

Regards,

Oliver