変更の追跡を含むフルテキストカタログ：そのテーブルの変更追跡が有効になっていない場合、AUTOは自動的に更新されますか？

フルテキストインデックスを最新の状態に保つためのデータベーステーブルがあります。ただし、これが発生しているのはまったくわかりません（最後に表示されたログは手動でトリガーしたときだったため、ログにエラーはありません）。

これが私が見ているものです...

テーブルの上に...

これが自動的に行われない理由ですか？

— メタグル
ソース

わかりやすくするために、どのログを参照していますか？

— Mike Zalansky、2015

@mikezalanskyその全文ログは次の場所にあります(..\MSSQL\Log\SQLFT*)

— Kin Shah

回答:

あなたは間違った場所を見ています。

次のように確認する必要があります。

T-SQLの使用

Use database_name
go
ALTER FULLTEXT INDEX ON schema.table_name SET CHANGE_TRACKING AUTO;

完了したら、最後に入力された日時のステータスを確認できます

-- script source : http://stackoverflow.com/a/10505496/1387418
-- Modified by Kin on Dec 14' 2015 to reflect the FTCatalogName
DECLARE @CatalogName VARCHAR(MAX)
SET     @CatalogName = 'AW2008FullTextCatalog' -- change here !

SELECT name as FTCatalogName, 
    DATEADD(ss, FULLTEXTCATALOGPROPERTY(@CatalogName,'PopulateCompletionAge'), '1/1/1990') AS LastPopulated
    ,(SELECT CASE FULLTEXTCATALOGPROPERTY(@CatalogName,'PopulateStatus')
        WHEN 0 THEN 'Idle'
        WHEN 1 THEN 'Full Population In Progress'
        WHEN 2 THEN 'Paused'
        WHEN 3 THEN 'Throttled'
        WHEN 4 THEN 'Recovering'
        WHEN 5 THEN 'Shutdown'
        WHEN 6 THEN 'Incremental Population In Progress'
        WHEN 7 THEN 'Building Index'
        WHEN 8 THEN 'Disk Full.  Paused'
        WHEN 9 THEN 'Change Tracking' END) AS PopulateStatus
FROM sys.fulltext_catalogs

データを挿入します。

insert into HumanResources.JobCandidate
(BusinessEntityID, Resume, ModifiedDate)
values 
    (4, NULL, DEFAULT)

これで、FTカタログが更新されたことがわかります。

ログ（..\MSSQL\Log\SQLFT*）にも、以下のメッセージが表示されます...

2015-12-14 12：36：51.29 spid50s情報：テーブルまたはインデックス付きビュー '[AdventureWorks2012]。[HumanResources]。[JobCandidate]'のフルテキスト自動生成が完了しました（テーブルまたはインデックス付きビューID '1589580701'、データベースID ' 5 '）。処理されたドキュメントの数：1。失敗したドキュメントの数：0。再試行されるドキュメントの数：0。

BOLから：

デフォルトで、またはCHANGE_TRACKING AUTOを指定した場合、フルテキストエンジンはフルテキストインデックスで自動生成を使用します。最初の完全な作成が完了すると、ベーステーブルでデータが変更されるときに変更が追跡され、追跡された変更が自動的に伝達されます。ただし、フルテキストインデックスはバックグラウンドで更新されるため、伝達された変更がすぐにインデックスに反映されない場合があります。

デフォルトでは、SQL Serverは新しいフルテキストインデックスを作成するとすぐに完全に入力します。ただし、人口全体が大量のリソースを消費する可能性があります。そのため、ピーク時にフルテキストインデックスを作成する場合、特にフルテキストインデックスのベーステーブルが大きい場合は、ピーク時以外の時間まで全人口を遅らせることがベストプラクティスであることがよくあります。ただし、インデックスが属するフルテキストカタログは、そのフルテキストインデックスのすべてが入力されるまで使用できません。

また、フルテキストインデックスのパフォーマンスの向上も参照してください。

— キンシャー
ソース

ありがとう！私が見ている問題は、手動でインデックスを再構築するまで更新されないように見える理由です。関連しているかどうかはわかりませんが、この問題が最も発生していると思われるデータベースは、ミラーリングされているデータベースです。

— MetaGuru

Issue I am looking at is why it doesn't seem to update at all until I manually rebuild the index.私が示したとおりに設定しましたか？多くの変更がある場合、それからしばらく時間がかかります

The full-text index is updated in the background, however, so propagated changes might not be reflected immediately in the index.

— Kin Shah

ええ、私はあなたが示した場所をチェックし、例のように正しく構成されました...奇妙なことに、ログがこのインデックスが更新されたと最後に言ったのは、数週間前でさえ、新しい行が最後に追加されたときと比較してです。この権利に従って新しい行が追加されたときに実行されますか？

— MetaGuru

はい..私はテストしてから、回答として投稿しました。

— Kin Shah

なんらかの理由で、セカンダリアベイラビリティグループデータベースのレプリカが引き継いでプライマリレプリカになった後、フルテキストインデクサーがSQL 2012データベースの1つで自動入力を停止しました。

全文索引を削除し、自動入力をオンにしてテーブルに再作成した後、自動入力が再開されました。SQL Management Studioとフルテキストインデックス作成ウィザードを使用して、インデックスを再作成しました。

データの完全なインデックス作成を実行するのにかかる時間を心配していました。547619レコードのテーブルから3つのテキスト列のインデックスを再作成するのに約5分しかかからなかったので、うれしい驚きでした。

質問で言及されているテーブルレベルの変更追跡設定は無効のままでした。したがって、フルテキストインデックスの変更の追跡は、テーブルの変更の追跡の設定とは明らかに異なります。全文索引の変更追跡と全文索引の自動入力が機能するために、テーブル変更追跡を有効にする必要はありません。

データベースから次のクエリを実行すると、フルテキストインデクサーが最後にクロールを実行した時間がわかります。

  SELECT  * FROM sys.fulltext_indexes

自動入力がオンの場合、データをテーブルに挿入した後、crawl_end_dateが変更されます。

また、フルテキストインデックスを使用するクエリを実行すると、最新のデータが表示されることに注意してください。

  select TOP 10 * from YOURDATATABLE where contains((YOUR_indexed_column),'YOURSEARCHTERM') order by YOURPRIMARYKEYCOLUMN desc

その他の参考資料：

全文検索の母集団のさまざまな方法を説明する記事：https : //msdn.microsoft.com/en-us/library/ms142575%28v=sql.100%29.aspx

全文索引テーブルのクエリに関する情報：https : //technet.microsoft.com/en-us/library/ms142571(v= sql.110).aspx#queries

全文検索アーキテクチャに関する記事：https : //technet.microsoft.com/en-us/library/ms142571(v=sql.110).aspx#architecture

— WWC
ソース