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.
Indexing Strategies
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.
EQStamp
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 Key
is 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 EQStamp
(in 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 <events timingLevel="high">
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.
The explanation of EQStamp and Stamp relation is very helpful. Thanks, Mark!