I would expect that the destination DB server has a "bulk load" utility, and this tool should make it possible for a complete replacement of table data to be very simple and very quick, with proper attention to blocking access by others while this is in progress.

In other words, go with option 1, and spend your time making sure you use the right tools in the most effective way possible, to make the whole procedure as quick and simple as possible.

Option 2 is a lot more work, not only in terms of the initial difficulty of writing the appropriate code, but also in the amount of processing time needed for it to work as intended (along with the associated amount of resource consumption; cpu/server load, 1 of 10 connections tied up for a longer period, etc). Then there's the problem that it will be more difficult to maintain or adapt over time.

I think the coding and execution time for a well-designed "option-1" approach will be very attractive: it should be easy and quick to design and run the appropriate query from the source DB, to design and run a suitable perl script to do any additional filtering/editing on the query output (in case some adjustments are easier to do in perl than in sql), and to work out the appropriate bulk load process for the destination table.