So it's not write_sdc to get around your existing .sdc, but to explicitly get around the DDR3 from being run. What version of Quartus was your UniPHy generated in? There are some versions where it ran really slow. (And to be honest, there still are...)
The quick way to check is to look at the failing path and analyze it in the original design(although it may not exist since calibrated clocks are removed from back-end analysis, as they would show up as failing).
It's not designed to be run this way, and just running the write_sdc is most likely going to show failures that aren't real(due to calibration) or worse yet not analyze paths correctly. The more fundamental problem is that the uniphy .sdc constraints are taking too long to run. You might want to file an SR case, and make sure you're running with a recent version of them(some old stuff has been fixed, but I have seen cases where new Stratix V cores with many DDR3 instances takes a long time).