The following is the sequence recommended by Adobe. A sample RHEL 6.3 shell script that invokes these operations using curl is available for download here.
ONCE PER DAY
The elapsed times reported below are for a virgin CQ “author” instance with about 70,000 nodes and about 350,000 properties hosted on an SSD.
2) Tar Index Merge
3) Tar Optimization (~ 2 minutes)
This defragments the repository Tar files. For massive DAM ingestion operations, here is a model that can predict how long this would take.
4) Tar Index Merge (again)
The automatically scheduled Tar optimization does in fact do an index merge, Tar optimize, and a second index merge.
FOR DEV Environment:
5) Consistency Check (~ 3 seconds)
6) Traversal Check (~ 4 seconds)
In addition, the following CQ Knowledge Base article discusses ways to prevent repository inconsistencies from occurring. Here are links to the sample (v5.6)repository.xml, workspace.xml and start.bat (Windows). Please note that these settings do slow down CQ startup times, the bigger your repository, the longer the startup.
ONCE PER WEEK
1) Datastore Garbage Collection (~ 4 minutes)
This removes orphaned files in the datastore that are no longer referenced from within the repository. The bigger the data store, the longer this operation will take. See this for a model to predict this.
If your repository is large, you can choose to start the following operations at a level lower than at the top (/ which represents the root of the hierarchical Java Content Repository). E.g. /content/dam/MySite1Assets for Start Path.