Индексы

Без DAG https://practical365.com/exchange-server/fix-failed-database-content-index-exchange-2013/

C DAG:

https://practical365.com/exchange-server/fix-all-failed-exchange-database-content-indexes/

PowerShell Tip: Fix All Failed Exchange Database Content Indexes

FEBRUARY 25, 2013 BY PAUL CUNNINGHAM 67 COMMENTS

One of the issues that my Get-DAGHealth.ps1 script alerts for is failed content indexes on database copies in a database availability group.

Note: for failed content indexes on servers that are not DAG members refer to this article instead.

Failed content indexes can easily go unnoticed when everything else is working fine however they will eventually begin to cause problems for you, for example by preventing database switchovers.

Fixing a single failed content index is easy, but if there are multiple failed indexes you can speed things up a little by fixing them all with a single PowerShell command.

To demonstrate, here is the Exchange Management Shell command for using Get-MailboxDatabaseCopyStatus to display all database copies that have a content index in a failed state.

1 2 3 4 5 6 7

[PS] C:\>Get-MailboxDatabaseCopyStatus * | where {$_.ContentIndexState -eq "Failed"} Name                               Status     CopyQueue ReplayQueue LastInspectedLogTime   ContentIndex                                    Length     Length                                       State ----                               ------     --------- ----------- --------------------   ------------ Mailbox Database 1HO-EX2010-MB1   Healthy    0         0           22/02/2013 10:43:26 AM Failed Mailbox Database 2HO-EX2010-MB1   Healthy    0         0           22/02/2013 10:41:36 AM Failed

So all we need to do is pipe the output of that command into the Update-MailboxDatabaseCopy cmdlet with the -CatalogOnly switch.

1	[PS] C:\>Get-MailboxDatabaseCopyStatus * | where {$_.ContentIndexState -eq "Failed"} | Update-MailboxDatabaseCopy -CatalogOnly

Wait for that process to complete, then re-run the first command again. If no results are returned this time then there are no more failed content indexes.

Индексация и Exchange 2016

2 Votes

Меня страшно ругали в комментариях: мол спустись на землю уже и пиши про проблемы “простой нарот”. Пишу. Налетели на крайне интересное поведение в 2016. На одном из почтовых серверов в DAG перестал работать поиск. Как понятно, была применена классическая инструкция TR, и состояние статуса индексов писало в ЕСР “Исправен“. Но оно и до проблемы так писало, т.е. не поменялось ничего. Странность проявилась в том, что папки со гуидами на диске не создавались. Видели вы когда-нибудь такое? И по-прежнему было сообщение “Healthy”.

Было принято решение свериться с тайным местом и выставить серверу ключи Failed And Suspended = 5, чтобы он прекратил отпираться и все-таки начал чинить индекс. Сервер этого делать не пожелал , поэтому решили попробовать стянуть со здоровой копии.

При попытке выполнить Update-MailBoxDatabaseCopy db03\exch1 -CatalogOnly получили следующее:

ошибка ПРЕДУПРЕЖДЕНИЕ: Не удалось заполнить каталог индекса контента для базы данных “DB03”. Убедитесь, что службы поиска и
контроллера узлов Microsoft Exchange работают, и повторите попытку. Ошибка: Прослушивание на
net.tcp://localhost:3863/Management/SeedingAgent-372C55FE-F874-4BC0-BFD1-75AE7F60880A12/Single не выполняла ни одна
конечная точка, которая могла бы принять сообщение. Среди прочих причин это могло быть вызвано неправильным адресом или
действием SOAP. Подробнее см. в описании InnerException (если имеется).

В системных событиях также ошибка с кодом 1012

Exchange Server Information Store has encountered an error while executing a full-text index query (“and(subject:string(“SearchQueryStxProbe*”, mode=”and”), folderid:string(“3EDA72446438D348A4A75A7B10DC8B7F00000000010C0000″))”). Error information: System.ServiceModel.EndpointNotFoundException: Сообщение не удалось отправить, так как адрес конечной точки “net.pipe://localhost/3867” недоступен для протокола адреса.

Стало понятнее, что лечить будем старым добрым средством:

cd “C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\Installer”

.\installconfig.ps1 -action I -datafolder “%ExchangeInstallPath%\Bin\Search\Ceres\HostController\Data”

И тут же статусы поменялись на “Обход содержимого”

Не хочется поднимать панику и кричать, что это баг CU8, но такое вижу первый раз – индексы сломаны, и только после пыток сервер сознается, что таки да, была покража, до этого он танцует и поет песни что все хорошо и никаких ошибок нет.

В общем, как всегда, будьте внимательны и осторожны и берегите себя.