Shrink a mirrored and replicated DB
Shrinking can have a massive impact on the transaction log, which in turn can dramatically impact the performance of mirroring and, I think to a lesser degree, replication.

My suggestion is: don't try to wave some wand and recover 200+GB right now, but instead, do it in chunks, gradually. Every night or every 6 hours or on some other reasonable interval, run one of these commands:

-- day 1
DBCC SHRINKFILE(data_file_name, 245000);

-- day 2
DBCC SHRINKFILE(data_file_name, 232500);

-- day 3
DBCC SHRINKFILE(data_file_name, 225000);


Yes, that is less satisfying, and obviously takes longer, but who cares? How badly do you need that space right now? Your features and users will be better off without that massive disruption IMHO.

An alternative would be to turn off mirroring and/or replication, and reinitialize them completely once the shrink operation is done (and you have backed up the log and made it the normal size, too). But I think just shrinking a bit at a time is far less complicated, disruptive, and risky.