Change Tracking VS Update Index

When creating a new Table Schedule, there is an option for a Job Type of
"Update Index". I though this was Change Tracking, but it doesn't seem to
be. I still had to manually select Change Tracking from the full text menu.
What is Update Index?
Thanks
It is, but change tracking has two modes:
1) update index is a scheduled update, ie you can update the index on demand
or as a scheduled job
2) update index in background - ie have it happen continuously
"Don Schilling" <fake@.ReplyToGroup.com> wrote in message
news:OMa3r$2PEHA.648@.TK2MSFTNGP10.phx.gbl...
> When creating a new Table Schedule, there is an option for a Job Type of
> "Update Index". I though this was Change Tracking, but it doesn't seem to
> be. I still had to manually select Change Tracking from the full text
menu.
> What is Update Index?
> Thanks

Change Tracking in SQLserver

What is change Tracking in SQL serverhttp://msdn2.microsoft.com/en-us/ms142575.aspx

change tracking for SQL Server

Has anyone come across a change tracking tool for SQL Server. Specifically
the scenario I want is the following :

A Production DB needs some modifications to its content.
This tool will copy the DB to a dev environment.
The Dev environment will be 2 copies of the DB, 1 as a control set and the
other the change DB.
The developer makes their changes in the Change DB. They test them out and
then when they decide the changes are ready to pushto production they hit
the "go" button on the tool.
The tool calculates the delta between the Control and the Change DB and then
pushes the changes to produciton

Any ideas

Thanks

s"Steve Mew" <steve_mew@.hotmail.com> wrote in message news:<wWnib.8720$843.5779@.nwrddc03.gnilink.net>...
> Has anyone come across a change tracking tool for SQL Server. Specifically
> the scenario I want is the following :
> A Production DB needs some modifications to its content.
> This tool will copy the DB to a dev environment.
> The Dev environment will be 2 copies of the DB, 1 as a control set and the
> other the change DB.
> The developer makes their changes in the Change DB. They test them out and
> then when they decide the changes are ready to pushto production they hit
> the "go" button on the tool.
> The tool calculates the delta between the Control and the Change DB and then
> pushes the changes to produciton
> Any ideas
> Thanks
> s

I'm not aware of a single tool that would do exactly what you want,
however you could start by looking at the Red Gate SQL tools
(http://www.red-gate.com), which can compare two databases and
generate scripts to synchronize them. There are similar tools from
other vendors.

Copying the databases is easily automated (backup/restore, SQLDMO,
DTS), but you might want to consider the permissions involved. Many
sites do not allow developers to backup/restore databases or push code
directly to production (although to be fair, there are certainly many
that do).

Simon|||Steve Mew (steve_mew@.hotmail.com) writes:
> Has anyone come across a change tracking tool for SQL Server. Specifically
> the scenario I want is the following :
> A Production DB needs some modifications to its content.
> This tool will copy the DB to a dev environment.
> The Dev environment will be 2 copies of the DB, 1 as a control set and the
> other the change DB.
> The developer makes their changes in the Change DB. They test them out and
> then when they decide the changes are ready to pushto production they hit
> the "go" button on the tool.
> The tool calculates the delta between the Control and the Change DB and
> then pushes the changes to produciton

For the scenario you describe it sounds like SQL Compare from Red Gate
is the tool to use. However, I have never used this tool myself.

I cannot escape to take the occassion to point out that the best strategy
would be have all your source in a version control system, and then have
controlled procedures from building update scrtips from the version-
control system.

--
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp

Change Tracking Displayed in Event Log

I have a customer that is complaining of poor performance when doing
searches against the FTS catalog during the day.
I believe what is happening is that the indexing process is taking place at
the same time as their searches.
select @.@.version
Microsoft SQL Server 2000 - 8.00.760 (Intel X86)
Dec 17 2002 14:22:05
Copyright (c) 1988-2003 Microsoft Corporation
Standard Edition on Windows NT 5.0 (Build 2195: Service Pack 4)
The data is derived from an OCR process on scanned forms.
The data is added to the table throughout the day.
The catalog index is on one column of one table.
I have Change Tracking, Update Index in Background enabled.
Question 1 - When Chg Trk, UIB is enabled, should I see the crawl start and
crawl end events enumerated in the event log?
I thought this operation went on continuously.
I have included an abridged listing from the event log for one day.
You can see that on average, 200-300 items are processed each iteration
during the day.
Is this typical of Change Tracking, UIB?
The following list displays the data for one day,
crawl start time
crawl end time, gatherer count, modified count
7:21 crawl start
8:43 crawl end 2031581 6
9:04 crawl start
10:29 crawl end 2033495 307
11:01 crawl start
12:22 crawl end 2034510 385
12:50 crawl start
14:14 crawl end 2035862 341
14:23 crawl start
15:49 crawl end 2036796 244
16:27 crawl start
17:48 crawl end 2038034 244
19:00 crawl start
20:21 crawl end 2038557 1
Since the crawl process runs for one to one and one-half hours each event, I
am guessing that this is what is affecting their performance.
Question 2 - Would it be better to turn off Change Tracking, UIB during the
day and start an incremental index in the evening?
I thought CT, UIB was designed to allow indexing to take place while normal
database operations are executing.
This depends on your needs. If you need real time indexing updates you will
probably have to use Change tracking with Update Index in Background.
Otherwise, you might want to use Change Tracking and then schedule the index
update to periods when there is low activity on the server.
Note that there are dramatic improvements with SQL Server FTS in SQL Server
2005.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Binder" <rgondzur@.hotmail.com> wrote in message
news:eZPShpwLFHA.2888@.TK2MSFTNGP12.phx.gbl...
> I have a customer that is complaining of poor performance when doing
> searches against the FTS catalog during the day.
> I believe what is happening is that the indexing process is taking place
at
> the same time as their searches.
> select @.@.version
> --
> Microsoft SQL Server 2000 - 8.00.760 (Intel X86)
> Dec 17 2002 14:22:05
> Copyright (c) 1988-2003 Microsoft Corporation
> Standard Edition on Windows NT 5.0 (Build 2195: Service Pack 4)
> The data is derived from an OCR process on scanned forms.
> The data is added to the table throughout the day.
> The catalog index is on one column of one table.
> I have Change Tracking, Update Index in Background enabled.
>
> Question 1 - When Chg Trk, UIB is enabled, should I see the crawl start
and
> crawl end events enumerated in the event log?
> I thought this operation went on continuously.
> I have included an abridged listing from the event log for one day.
> You can see that on average, 200-300 items are processed each iteration
> during the day.
> Is this typical of Change Tracking, UIB?
>
> The following list displays the data for one day,
> crawl start time
> crawl end time, gatherer count, modified count
>
> 7:21 crawl start
> 8:43 crawl end 2031581 6
> 9:04 crawl start
> 10:29 crawl end 2033495 307
> 11:01 crawl start
> 12:22 crawl end 2034510 385
> 12:50 crawl start
> 14:14 crawl end 2035862 341
> 14:23 crawl start
> 15:49 crawl end 2036796 244
> 16:27 crawl start
> 17:48 crawl end 2038034 244
> 19:00 crawl start
> 20:21 crawl end 2038557 1
>
> Since the crawl process runs for one to one and one-half hours each event,
I
> am guessing that this is what is affecting their performance.
> Question 2 - Would it be better to turn off Change Tracking, UIB during
the
> day and start an incremental index in the evening?
> I thought CT, UIB was designed to allow indexing to take place while
normal
> database operations are executing.
>
>