Not another one of these posts — troubleshooting indexing issues with Sitecore?! Well, I wanted to quickly provide some guidance on ways to troubleshoot indexing. Read on to learn a bit about indexing and things to look out for as you troubleshoot issues.
Part of the indexing configuration in Sitecore includes indexing strategies that you select from. These are C# classes that run at indexing time based on how you want the system to behave. The default strategy in a stock instance for the “web” database is
onPublishEndAsync. This strategy uses the event queue to subscribe to the
publish:end event. When raised, it triggers an incremental index update (i.e. not a full index rebuild but small deltas directly on the index). So how does this actually work to update the index? If you’re having indexing issues with this strategy then continue reading.
The event queue keeps a record of events fired on instances of Sitecore. Each instance polls the queue to check for changes. The
onPublishEndAsync strategy first finds the
EQStamp property for the Sitecore instance in the Core database’s
Properties table. The format for the
EQStamp_<instance name> and the value is a sequentially updated decimal.
The strategy then finds all records in the event queue that are remote (i.e. fired by another instance such as a CM) and have occurred since the
EQStamp. It does this by scanning the records and comparing the
Stamp column (in
EventQueue) to the
Properties). That said, the
Stamp column is in hexadecimal format, so it needs to convert to decimal to compare these values.
Compare EQStamp and Stamp
How does this help you? To troubleshoot indexing issues, clear your event queue table contents and delete any
EQStamp values in
Properties. A simple query like this will do:
DELETE FROM Properties WHERE [Key] LIKE 'EQStamp%'
Make some change in the CMS and publish your content to web. This will fire events and seed the event queue with some data. Next, get the most recent events like so:
SELECT * FROM EventQueue ORDER BY Created DESC
Next, open up Google (you may have heard of it) and convert the latest value of the
Stamp column to decimal (e.g. search for 0x3B64 to decimal). Now compare this value to the
EQStamp. If its greater than
EQStamp then this record in the queue has not been processed. If it equals the
EQStamp then Sitecore has processed the event and should update the index.
Things to consider
If the queue isn’t being processed based on the data from above, make sure you don’t have any errors in the logs. You can also increase the logging verbosity to get more intel on possible issues:
<log4net> <logger name="Sitecore.Diagnostics.Crawling" additivity="false"> <level value="DEBUG" /> <appender-ref ref="CrawlingLogFileAppender" /> </logger> <log4net>
As well as
Additionally, make sure your versions of Sitecore match between instances. It sounds silly, but this happened to me before where a CM and CD were off by a minor revision and indexing failed to work properly.
Finally, another way to peek in on what’s going on is to use Microsoft’s Process Monitor and sniff activity from
w3wp. Fire it up, go to Filter > Filter, and add Process Name contains w3wp.