Repository not reducing even after deleting lot of dam assets AEM 6.4

[NituDh]

I have almost clear whole dam via script and tested. Sites are working fine. all dam folders and assets added by users are deleted. and then run 
1. java -jar oak-run-1.8.4.jar checkpoints crx-quickstart/repository/segmentstore
2.  java -jar oak-run-1.8.4.jar checkpoints crx-quickstart/repository/segmentstore rm-unreferenced
3.   java -jar -Dsun.arch.data.model=32 oak-run-1.8.4.jar compact crx-quickstart/repository/segmentstore
after compact however it freed the size of 35GB. but my aem total size was around 865GB. and I was expecting to reduce more used size. however I haven't deleted the sites which were using these assets. The dam size was quite big in 700+GB.
Can someone guide me how to clear the size of application?
Server used is Rhel 9.

[BrianKasingli]

This sound like you're definitely on the right track by deleting DAM assets and running oak-run to compact the repository, but there are a few key reasons why the overall size of your AEM instance might not be reducing as much as expected — especially in AEM 6.4.

Why the Repository Size Didn't Drop Much:

1. Pages May Still Reference Deleted DAM Assets
   Even though the assets are gone from /content/dam, site pages that were using them might still contain references (like fileReference or data properties). These lingering references can prevent the garbage collection and compaction process from fully cleaning them out.
2. Version History Still Retains Data
   AEM automatically stores older versions of assets and pages under /jcr:system/jcr:versionStorage, which can build up over time. Deleting assets doesn’t automatically remove their version history — and that version history can be huge.
3. Workflows, Audit Logs, and Other System Nodes Add Up
   Paths like /var/workflow/instances, /var/audit, and /var/eventing can grow silently and hold on to data even after assets are deleted. These should also be purged regularly.
4. Assets Might Be Embedded in Pages Instead of Stored in DAM
   In some cases, assets are uploaded directly inside components at the jcr:content level of a page, like:
   • /content/mysite/en/page/jcr:content/image/file
     These types of binary files don’t live in DAM, so deleting DAM assets doesn’t affect them — and since they’re tied to pages, they also get versioned. This is one of the reasons why using the DAM (/content/dam) is a best practice in AEM: it keeps assets centralized, processed by asset workflows, and much easier to manage and clean up.

What You Can Do Next:

1. Run a version purge: Use the official Adobe AEM Version Purge Configuration: https://experienceleague.adobe.com/en/docs/experience-manager-65/content/implementing/deploying/conf... to automatically remove old versions of assets and pages. This helps clear data stored under /jcr:system/jcr:versionStorage.
2. Check for embedded binaries in /content: Use a query or Groovy script to scan for file nodes or jcr:content/renditions under your site structure. These are often large, directly embedded binaries that don’t live in DAM and can silently grow over time.
3. Purge workflows and audit data: Clean up system paths like /var/workflow, /var/audit, /var/eventing, and others that may store large logs or payloads long after they're needed.

Re-run oak-run compaction after the cleanup steps — and make sure AEM is fully stopped when doing this to ensure maximum cleanup efficiency.

Let me know how it goes.