Cannot shrink large database file

I have a server that is running SQL 2000. There is one large database 200
GB in size made of three files in the primary file group. We just freed up
40 GB of space in the db by archiving a table. The taskpad of SQL indicates
all this comes from the first file in the primary filegroup.
Our problem is that we've had a ton of trouble shrinking it down. We've
tried shrinking increments, with TRUNCATEONLY (after NOTRUNCATE). We
haven't done empty file because we do not want to remove the file. Out of
all of our attempts, only one try has succeeded in removing 10 GB, and that
took 4 hours. DBCC CHECKDB shows no errors, we did a backup successfully.
It just looks like it is running slow with high CPU and DISK I/O. The data
files are all on a fiber-optic SAN. Any suggestions? Thanks.

*************************************************
Andy S.
andymcdba1@.noreply.yahoo.com
Please remove "noreply" before replying.
*************************************************
The shrinking process usually is very painful and resource intensive. How
long it takes usually depends on the hardware and how much activity you have
in that file. In order to shrink the file SQL Server needs to move any data
pages near the end of the file towards the beginning of the file. This is a
fully logged operation and can be blocked just like any other process that
updates pages. 40GB in a 200GB db is not that much free space. You need
plenty of free space on a regular basis to handle things like reindexing
anyway. If you must shrink then use SHRINKFILE vs. SHRINKDATABASE and make
sure when you are done that all the files in the file group are the same
size. Have a look here:
http://www.karaszi.com/SQLServer/info_dont_shrink.asp Shrinking
considerations
Andrew J. Kelly SQL MVP
"Andy S." <andymcdba1@.noreply.yahoo.com> wrote in message
news:%23D6br50bFHA.3048@.TK2MSFTNGP12.phx.gbl...
>I have a server that is running SQL 2000. There is one large database 200
>GB in size made of three files in the primary file group. We just freed up
>40 GB of space in the db by archiving a table. The taskpad of SQL
>indicates all this comes from the first file in the primary filegroup.
> Our problem is that we've had a ton of trouble shrinking it down. We've
> tried shrinking increments, with TRUNCATEONLY (after NOTRUNCATE). We
> haven't done empty file because we do not want to remove the file. Out of
> all of our attempts, only one try has succeeded in removing 10 GB, and
> that took 4 hours. DBCC CHECKDB shows no errors, we did a backup
> successfully. It just looks like it is running slow with high CPU and DISK
> I/O. The data files are all on a fiber-optic SAN. Any suggestions?
> Thanks.
>
> --
> *************************************************
> Andy S.
> andymcdba1@.noreply.yahoo.com
> Please remove "noreply" before replying.
> *************************************************
>