Yep! This will most definitely affect performance during the process, and it sounds like it could take a long time.

Points to consider:

1) You should definitely use DBMS_STATS as this allows the operation to act in parallel. Use the DEGREE parameter to specify the degree of parallelism.

2) Use an estimate since this will reduce the number of rows sampled to gather some of the statistics. I often use 15%, but with an extremely big table this may still be an extremely big sample so you may want to go lower.

An alternative if you have the server space to do it is to transfer the stats from another server. ie.

1) Build a clone of your database.
2) Calculate the stats on the clone.
3) Save (export) the stats to a stats table.
4) Export stats table.
5) Import stats table to production server.
6) Load (import) stats into data dictionary from stats table.

Disco!

This will require lots of space on a development box but it will mean that the stats gathering will be almost instant as far as the production environment is concerned.

I often use this method in reverse to make sure development boxes have the same stats as production boxes, hence similar execution plans.

Cheers