In SharePoint every content database contains an EventCache table that is the “change log” for objects contained in the database. Each row in the table is depicting a change in an object. Columns in the table contain information such as the date and time of a change, the type of object that was changed, the nature of the change, and a unique identifier for the object.
Sharepoint has a “Change Log” Timer job for each web-application which is scheduled to run on a Weekly basis. This job removes expire entries from the Change log of the respective web-application.
Expiration of the change logs will happen based on the ChangeLogExpirationEnabled and ChangeLogRetentionPeriod properties of the web application. Timer job called “Immediate alerts” which then processes all the events in the change log and & send out alert to users who have subscribed alerts for. This timer job then marks the EventCache entry as processed and updates the last processed event details in EventBatches table
There are situations I have seen where the Event cache table is huge (millions of rows) & they are not being cleaned up as expected. Even when you detach the database from SharePoint & attach it back with –clearchangelog switch the EventCache table is not purged.
One of the reasons this happens is because the “Immediate Alert” timer job is disabled. This would lead to alerts being unprocessed & the Change Log Cleanup job will ignore the unprocessed entries.
One needs to Simply Enable Immediate alerts timer job web application by going to Central admin, Monitoring and Review job definitions page.
Note: Immediate alert job will process couple of 1000s of record at each run. If there are millions of records to be processed and cleaned up, then you may have to schedule the immediate alert and Change log timer jobs to run more frequently than the default schedules.
By now most of us know that in SharePoint 2010 we have Metadata Services which help us manage the cotent types across site collections, web apps, farms. It helps us define a hub site collection (to say it is the place where we define our all content types and we can also call it as PROVIDER OF CONTENT TYPES).
Lot of information is already available on this on net.
So I thought of trying this wonderfull feature and followed the steps:
1,Created a new site collection called PROVIDER HUB Content Types.
2.Added this as a Hub in the Metadata Service Application,associated the Web App to this service
Created a Content Type “MyFirstContentType” in the hub site collection (step 1)
3.Created a new site collection CONSUMER, and now I assumed that this content type to should be available (as the web-application for this site collection uses the same Managed Metadata Service. But to my surprise that CT was not available. I thought my understanding is wrong about this new feature so I tried to look around and found that:
- I checked the managed metadata service proxy and made sure the checkbox for the option to Consume content types from the content type gallery and Push down content type publishing updates from the content type gallery. So basically all 4 checkboxes were checked.
Then realized that there are two important TIMERJOB “Content Type Subscriber” for every consuming web-app & “Content Hub Job(When you unpublish a published content type, any copies of the content type that are being used on sites that subscribe to this hub will become unsealed, which means they will no longer be read-only and they can be managed locally on the sites where they are in use. Based on my understanding, this is managed by the content type hub timer job.)” that I could see in the Central Admin so I manually kicked the two timer jobs: Content Hub job, and then the Content Type Subscriber
That’s it now I had the new content type in my Consumer web-application.
So just remember if you make any changes to the CONTENT TYPES in the HUB site collection and want it to be propagated immediately to the CONSUMING site-collections, lists, libraries just go to the Central Admin and manually kick of the CONTENT TYPE SUBSCRIBER TimerJob, this will ensure that the content type changes are propagated immediately to all the consuming list/libraries for that web-app. Remember that this timerjob is one per web-app.