If you manage Oracle Exadata environments, you rely on ExaWatcher to quietly collect performance diagnostic data in the background. Because ExaWatcher is standardized across nodes, Database Administrators (DBAs) and Exadata Direct Engineers (DMAs) generally expect archive retention to look uniform across identically configured environments. However, a common point of confusion arises during capacity audits: Why does one Exadata environment purge files older than 30 days and stay around 1 GB, while another retains months of historical archives up to 2.4 GB - despite having the exact same ExaWatcher configuration? In this post, we break down a real-world troubleshooting case across Development ( DEV ), Integration ( TESTINT ), and Quality Assurance ( QA ) Exadata database nodes to uncover how ExaWatcher actually governs archive retention, the hidden filesystem triggers inside ExaWatcherCleanup.sh , and how to safely manage historical archives. The Mystery: Identical Conf...