DB - IDES exploding on Mobile Clients - HELP

[Former Member]

Hello,

I'm facing a strong issue since few days. Everyday I have a mobile client which has it's IDES database full.

We are limited to 2GO on local machine and it's been only a 3 months we went live.

Some work has been done (on subscription etc) to limit the download of data , we have few attachements - but still we have this issue today and I was wondering if you know what I could do (on local machines for ex) to avoid this huge problem.

Thank you guys for your help,

Mi

[Former Member · Accepted solution]

Hi,

do you already have tried to defragment/shrink the local database? For this please refer to note 417539.

Especially after initial load or heavy data exchange this might help to lower the database volume.

The attached files to this note help you to do this job on a regular basis.

Regards,

Wolfhard

[andreasfrank_roth]

Hi,

reading all comments below I would suggest first thing: Analyze your IDES Databse which Dable has which Size. Based on this think about strategies to reduce this specific Dataobjects (or change to a different DB like the follow up of MSDE with 4 GB limit)

Andreas

[Former Member]

Hi Andreas,

Thank you for your reply.

I already did this : Top 4 biggests tables are

1. SMOATTACHCONT

as big as

2. SMOCONDXML <- these are conditions linked to sales doc aren't they ? The fact is that we already have shortened to the maximum (refering to our business process) the number of sales docs which arrive on Mobile Clients

3. syscomments <- what is in there? Is it possible to clean it?

4. SMOKNA1SHT

next we find :

SMOKNVVSHT

SMOVBPA

syscolumns

SMOMARC

SMOVBEP

I hope that reorganising DB every week could help us not to explode.... today I can't see an other solution.

(moving to SP12 - and MSDE 4Go is not possible now.)

Mi

[Former Member]

Hi,

here again some proposals regarding the table size:

1) do the mobile users really need those attachments from CRM resp do they really need to attach docs on mobile -> to limit the particular size see note 599680

2) in BDoc Modeler (Tx sbdm) you can find that SMOCONDXML indeed comes along with sales docs (or service docs as well). So no chance for reducing anymore as you mentioned...

3) better don't touch system tables, same for syscolumns...

4) SMOKNA1SHT/SMOKNVVSHT: Always a problem with those table sizes because of being distributed bulk (CUST_HIERARCHY). Depending of the business processes you could change the replication to intelligent supposed you may define a proper criteria. Alternatively you could make this replication object dependent from CAPGEN_OBJECT_WRITE. This would reduce the local store amount a lot but for achieving this you would need to change the replication (including deleting and redefinition of the replication object, running the complete R&R, removing cust hierarchy from all clients and reassign) which could have serious impact on a productive system.

5) SMOMARC is only included in PRDCT_OBJECT but not used anymore -> did you make some project enhancements there?

Regards,

Wolfhard

[Former Member]

We have recently changed the Cust_Hierarchy subscription to intelligent and it certainly helps a lot with data size.

Another problem that the bulk hierarchy can cause is if you have to re-extract it...it is such a large table that the sql dies when trying to process the zap

Beware, though... SMOKNA1SHT is referenced in MANY areas (opportunity BP search, person responsible search popup, contact person search popup).

You must make sure that you are careful when creating and assigning the subscriptions, otherwise you end up with a lot of nasty red messages caused by missing data on the clients.

One final thing to check...

Perform some queries on SMOCONDXML and check for duplicate entries. We had this problem in SMOCOND and ended up with a table with 900,000 entries instead of the 200,000 that we should have had.

Good luck

James

[Former Member]

Hi,

I know that this could be very dangerous therefore I mentioned "Depending of the business processes"...

This "Short object" is used in all BP popup searches and therefore in all partner objects linked to master & transactional data like orders or activities.

Therefore you have to analyze your data distribution very accurately and need to ensure that also the data coming from CRM to Mobile hold proper & consistent data (concerning the partner data). Otherwise changing/saving on Mobile is not possible anymore...

Regards,

Wolfhard

[Former Member]

Hello ,

Thank you again for your replies !

I'm still trying to find out a solution to my problems here and I realised (after another DB explosion one morning) that someone in some old time created for some specific data issue a Z_SOMETHING replication object typed "dependent" with no criteria fields and linked to CAPGEN_OBJECT_WRT . It also shares same publication obj. and suscription as CAPGEN. (which means "hell" if I want to change anything).

For me the only dependency you really have on these data is useful when you launch a complete extract for mobile clients (since the key is the BP number).

These specific data go to mobile clients once a day when a program is run (and specific bdoc created) .

We are suppose to have maximum one BDOC per BP ... BUT on a mobile client with 200 BPs I can get up to 3000 messages from the same object a day...

When I ask why this object was created as dependent and not intellignet with filtering the answer was " to optimize the middleware, entries in the Lookup table"... I still don't understand why..

(and I'm wondering to have some cust_hierarchy modification but for now I'm still analyzing the issue - I'm also going to make a cut on some attachments soon)

Anyway merry xmas to everyone and thank you again for your replies they help me to find te way to optimise my DBs !

[Former Member]

Hello and thank you again for your reply.

I know we have a limited MSDE and we could have a 4GB if we go to SP12 but now it's not planned so I have to find an other solution. (I'm going to script a DB reorg a week on our Mobile Clients, but I know it's not enough).

I noticed that one of my biggest table on IDES is SMOCONDXML which contains I suppose conditions linked to sales transaction.

Then I have those syscomments, sysindexes and syscolumns tables who are quite big even after reorganising my DB ... they are system tables they should empty by themselves , or not?

Anyway I'm still searching for a solution.

Cheers ,

Mi

[Former Member]

Hi,

I am sorry to say that only a redefinition of the data distribution could help (e.g. additional filtering on sales docs based on status etc) to avoid to keep old historical data on the laptop which is not needed anymore.

But also in case you were using unicode laptop configuration (which costs twice database storage amount!!!) you could think of using non-unicode local installation in case unicode is not used at all in your business processes.

Regards,

Wolfhard

[Former Member]

Hello and thank you for your reply.

I know about this Note and I ask the sales force team to run a reorg' of their database at least once a week.

The fact is that some of them can forget to do this and that I cannot check all the 200 Mobile Client database to see if they are reaching these 2GO Ides space or not.

I was wondering if someone knew an automatic solution (like a script running each week when PC is launched ) I could install on Mobile Client PC...

Thank you again for your replu,

Mi

[Former Member]

Hi,

of course you could do this automatically by sending the particular command file by client update via conntrans every week or month or even put this cmd file in the PC startup folder.

Obviously you were using MSDE because of the mentioned limitation. As far as I know this is changed to 4 GB for the newest MSDE version. For this you should check the PAM (product availability matrix) on SAP homepage.

Regards,

Wolfhard