> I've got a production database in FB 1.5.3. It contains about 1 million
> records in one table. These are fetched from an external source that's
> updated every two weeks. After each external update I need to update my
> production table. For this purpose I actually have two production

tables

> and use the following process:
>
> 1. Production system uses table 1.
>
> 2. Drop table 2 and recreate it.
>
> 3. Fill table 2 using three long-running queries (about 1 hour in

total).

>
> 4. Index table 2. Takes about half an hour.
>
> 5. Switch production system to use table 2.
>
> I need the process in steps 2-4 to run with low priority to make sure
> the production system is not impaired - this is a web application and
> requires good response times.
>
> What is the best way to achieve this? It would be possible to switch to
> classic, if that's any help. The server that hosts both DB, web server
> and web application has 1 Gbyte RAM, and a single harddisk (actually a
> mirrored pair). Windows 2003 server.
>
> Thanks,
> Kjell

I would avoid sleeping the thread as this could potentially cause more
bottlenecks then it resolves, especially if another thread has to wait
for the sleepy one to wake to release a lock.

If you switched to classic, then a UDF call could retrieve the process
ID and you could use that to change the priority class. I do not know
if this is advisable but it would certainly be less dangerous than
sleeping the thread.

Remember though that there is an overhead in slowing down the queries
in that there is a far greater garbage buildup and any locks will be
around for much longer, so I find it is usually better to get it over
with quicker.

You mention two tables and seem to toggle between them. Is there a
reason for doing it this way? If it is just an information lookup,
then you could put the data into a new database (on a different
machine) and then put the database in and change the alias.

Also, the hardware is relatively modest for something that is meant to
be both a database server, web server as well as handling data pumping.

Adam