4

We're proposing to delete no-longer-relevant Case Team Member records, numbering about 4.3 million (2.8 million total Cases). I'm concerned about the performance implications that might be caused by the sharing recalculations this touches off.

Both Case and Account have the Organization-Wide Default set to Private. There are several dozen sharing rules in place on Case, all of which are based on ownership.

I understand that Case Team membership grants an implicit parent share to the Account, and hence that parent-child data skew from Case to Account could cause very expensive sharing recalculations at difficult-to-predict points in the process of removing these records. We do have data skew, with about 400 Accounts having over 1,000 cases and 24 having more than 10,000 (the worse offender has north of 200k).

The mitigation that's usually recommended for this type of issue is to defer sharing rule calculation, which doesn't apply here, or to reduce data skew, which is a whole other ball of wax.

Are there other strategies I should be looking at to ensure that this bulk delete (a) can complete successfully and (b) does not negatively impact the performance of the rest of my instance? Alternately, am I unduly concerned, and may I simply expect that a bulk API job or batch takes a really long time to complete?

  • 2
    Two strategies I would recommend are: 1) Batch over Case records for exactly one Account at a time. 2) limit how many Case records you will delete teams for in one go. If you work incrementally over the course of several weeks/months, your odds of crashing anything seem way lower. Not sure it's feasible to remove this much data so tightly coupled with the sharing model in one go. Not that I've tried it myself, the above is all hypothetical. Also, if you work on increments and find that it's working fine, you can scale them up. – Adrian Larson Feb 16 '18 at 17:20
0

This actually shouldn't be a problem. The sharing table doesn't really have thousands of entries in its list (it's more of a view that's calculated from the base values). Sharing is also calculated synchronously, so if you're using a synchronous API (e.g. the Apex Data Loader), you should probably be okay. To be sure, though, make sure you run this process through a full copy sandbox, if you can, to see if any performance issues come up.

  • I may have misread the documentation; I thought that the defer sharing calculation feature only applied to group membership and evaluation of sharing rules. Does it cover any sharing calculation? – David Reed Feb 16 '18 at 19:31
  • @DavidReed Doh. No, I was the one who misunderstood. Thanks for pointing that out. – sfdcfox Feb 16 '18 at 19:33
  • The unexpected resolution was that a colleague accidentally cascade-deleted the majority of them over the weekend by removing associated Case Team Template Records, and we observed no performance impacts. Thanks! – David Reed Feb 20 '18 at 15:09
1

I have performed couple of bulk delete and Sharing recalculation related activities and here is my suggestions.

  1. Usually, this exercise needs to perform in a full copy sandbox though performance can defer with Production.

  2. This operation must be performed in off business hours (better to use weekend slots)

  3. Export millions to record using dataloader selecting Bulk API option and you can change the batch size up to 10,000. I have seen that it takes less than a minute to export 1 million record.

Bulk API option

  1. To delete the records use Bulk API hard delete option. Even if System Administrator profile normally doesn't have this permission. So, either create a custom profile or create a permission set, select the Bulk API Hard Delete option and assign to Admin user.

Good thing is that, data will not be in recycle bin and hence it will not be part of Sharing calculation. Salesforce calculates sharing even if records are in recycle bin.

  1. Just in case, if you receive "UNABLE TO LOCK ROW" error, then go to Dataloader Settings, and use Enable Serial Mode for Bulk API, so the it process batchwise operation serially. So, take the error log and again perform the delete operation with this settings.

  2. Monitoring: From Monitoring -> Bulk API Data Load Jobs, you can monitor job status and millions for data is not take significant time.

hard delete

  1. Before you run the job, be sure to deactivate trigger, emails etc which should not do negative effect.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.