We are trying to mirror several thousands of pages from one website to another website, the first time, i.e. initial mirroring takes very long time and a lot of memory. Sometimes we get a strange error that says deadlock, rerun transaction (see error message below). It seems that while EPiServer updates pages the indexer will try to index the page.
I read the following article http://labs.episerver.com/en/Blogs/Per/Archive/2008/6/Content-Generator-Preview/ that one could set the following parameter <siteSettings ... indexingDelayAfterPublish="00:00:00" ... in web.config to not index the pages when they are created.
To my question, how do I rebuild all indexes and statistics after my mirroring? We are running EPiServer CMS 5 SP3. Is there any stored procedure I can run?
Error message from log4net:"ERROR  EPiServer.DataAccess.DynamicPropertiesDB.LoadTree - 2.4.1 Dynamic properties load tree failedSystem.Data.SqlClient.SqlException: Transaction (Process ID 81) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.ERROR  EPiServer.LazyIndexer.Worker - 1.3.1 IndexPage failed for page 11049 System.Data.SqlClient.SqlException: Transaction (Process ID 81) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction."
The setting indexingDelayAfterPublish controls how long the built-in search functionality shall wait until it indexes HTML of your pages (using a queue and a background thread). Setting this value to zero means that for every publish it indexes the content synchronously instead of using that background queue, so you don't disable it. This has nothing to do with the SQL concepts indexes and statistics which I believe you are referering to. I guess my blog article was a bit confusing on that subject.
BTW, EPiServer CMS 5 R2 introduces a bunch of new SQL Server indexes to increase performance and minimize deadlocks due to for example table locks. I wrote another article about rebuilding SQL Server indexes if you are interested.
Ups, deleted my post when I wanted to edit...:-/
I did get past the initial mirroring of 3400 pages by rebuilding the indices on the database, I also deleted all items from the tblScheduledItemlog. The database process was hugging 99% CPU trying to update it I presume. I thought the maximum number of rows pr. task in the log was solved back in 4.61?