Increasing DBCC Performance

Use hardware with plenty of I/O capacity, since DBCC is I/O-intensive.
One good way to increase I/O capacity is to place the database on a large RAID disk array, using as many physical drives as possible.
Use hardware with plenty of RAM.
The ideal case would be sufficient RAM to enable the largest table to be contained in the SQL Server page cache. This is especially important on version 6.5 because the SQL Server page cache allows full use of parallel index checking and read ahead.
Ideally, you should run DBCC NEWALLOC, CHECKDB, CHECKCATALOG, and TEXTALL (if you have text/image data) in conjunction with your database dumps.
This verifies the state of the database at the time of the dump. However, if time does not permit all of these checks, the best single check to run is NEWALLOC. It is typically faster than CHECKDB and provides a good overall check of the database. It is better to run NEWALLOC alone than to run no checks at all.
If your database has a nightly interval where update activity is low, rather than setting the database to single-user mode for NEWALLOC, just run it and watch for any errors.
On the optimistic principle that most of the time the low activity will not cause spurious errors, you would only then need to schedule NEWALLOC in single-user mode when you see errors.
Although it is best to run both NEWALLOC and CHECKDB together, there are cases (for example, if the database is extremely large) when you would run them separately. For these cases, consider running NEWALLOC as the more frequent check, owing to the nonblocking nature and quicker running time it provides. On a less-frequent basis, supplement this with CHECKDB.
Run CHECKDB with the NOINDEX option.
The most time-consuming aspect of CHECKDB is checking nonclustered indexes. These checks can be bypassed with the following syntax:

DBCC CHECKDB(MYDB, NOINDEX)

Run DBCC on a hot backup server.
Sites with continuous uptime requirements often have a hot backup server on which transaction logs are loaded frequently. Otherwise, a failure on the main server would preclude continuous availability. If you have a hot backup server, it's possible to run DBCC on that server without impacting the main server. A DBCC run on the backup computer is just as valid and effective a test as a DBCC run on the main server.

If you do not have a hot backup server, the combined benefits of the safety net it provides plus the DBCC solution can be strong arguments for getting one.